Tracking issue for RFC #1909: Unsized Rvalues (unsized_locals, unsized_fn_params)
This is a tracking issue for the RFC "Unsized Rvalues " (rust-lang/rfcs#1909). **Steps:** - [ ] Implement the RFC (cc @rust-lang/compiler -- can anyone write up mentoring instructions?) - [ ] Adjust documentation ([see instructions on forge][doc-guide]) - [ ] Stabilization PR ([see instructions on forge][stabilization-guide]) [stabilization-guide]: https://forge.rust-lang.org/stabilization-guide.html [doc-guide]: https://forge.rust-lang.org/stabilization-guide.html#updating-documentation **Blocking bugs for `unsized_fn_params`:** - https://github.com/rust-lang/rust/issues/111175 - https://github.com/rust-lang/rust/issues/115709 (bad interaction with extern_type: we either need to be okay with post-mono checks or need a trait for "dynamically sized" types) - Reject unsized arguments for functions with non-Rust ABI **Related bugs:** - [x] https://github.com/rust-lang/rust/issues/61335 -- ICE when combined with async-await - [x] https://github.com/rust-lang/rust/issues/68304 -- `Box<dyn FnOnce>` doesn't respect self alignment **Unresolved questions:** - [ ] What are the MIR semantics for unsized locals? We currently do not have operational semantics for them, and the way they currently work, there are no good operational semantics. This needs a complete from-scratch re-design. - [ ] Can we carve out a path of "guaranteed no alloca" optimization? (See #68304 for some related discussion) - [ ] Given that LLVM doesn't seem to support alloca with alignment, how do we expec
Posted by aturon on Feb 7, 2018, 5:51 PM
Tags
Related issues
- Add 65536 size support for maps
- TypeScript 7.1 Iteration Plan
- nvim-treeconfig: upstream nvim-treesitter
- Add the "action" and "method" attributes to <button>
- [FEATURE] Support multiple Connector accounts (same connector, different accounts) in Claude and Claude Code on the web (claude.ai/code)
- > We were imposed GitHub for so many exercises!
Raise real-world problems, find people facing the same issue, and discuss solutions.4,500 issues0 comments
support (Software)
Add 65536 size support for maps
TypeScript 7.1 Iteration Plan
nvim-treeconfig: upstream nvim-treesitter
Add the "action" and "method" attributes to <button>
[FEATURE] Support multiple Connector accounts (same connector, different accounts) in Claude and Claude Code on the web (claude.ai/code)
> We were imposed GitHub for so many exercises!
Add support for Visual Studio 2026 Integration
Support for Helm v4
Tracking issue for RFC #1909: Unsized Rvalues (unsized_locals, unsized_fn_params)
This is a tracking issue for the RFC "Unsized Rvalues " (rust-lang/rfcs#1909). **Steps:** - [ ] Implement the RFC (cc @rust-lang/compiler -- can anyone write up mentoring instructions?) - [ ] Adjust documentation ([see instructions on forge][doc-guide]) - [ ] Stabilization PR ([see instructions on forge][stabilization-guide]) [stabilization-guide]: https://forge.rust-lang.org/stabilization-guide.html [doc-guide]: https://forge.rust-lang.org/stabilization-guide.html#updating-documentation **Blocking bugs for `unsized_fn_params`:** - https://github.com/rust-lang/rust/issues/111175 - https://github.com/rust-lang/rust/issues/115709 (bad interaction with extern_type: we either need to be okay with post-mono checks or need a trait for "dynamically sized" types) - Reject unsized arguments for functions with non-Rust ABI **Related bugs:** - [x] https://github.com/rust-lang/rust/issues/61335 -- ICE when combined with async-await - [x] https://github.com/rust-lang/rust/issues/68304 -- `Box<dyn FnOnce>` doesn't respect self alignment **Unresolved questions:** - [ ] What are the MIR semantics for unsized locals? We currently do not have operational semantics for them, and the way they currently work, there are no good operational semantics. This needs a complete from-scratch re-design. - [ ] Can we carve out a path of "guaranteed no alloca" optimization? (See #68304 for some related discussion) - [ ] Given that LLVM doesn't seem to support alloca with alignment, how do we expec
Comments (0)
No comments yet. Start the discussion.