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)
• Stabilization PR (see instructions on forge)

Blocking bugs for unsized_fn_params:

• unsized_fn_params allows some unsized locals #111175
• unsized_fn_params should not accept types that don't have a dynamically fixed size (such as extern types) #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:

• ICE when combining unsized locals and async #61335 -- ICE when combined with async-await
• Box<dyn FnOnce> doesn't respect self alignment #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 Box<dyn FnOnce> doesn't respect self alignment #68304 for some related discussion)
• Given that LLVM doesn't seem to support alloca with alignment, how do we expect to respect alignment limitations? (See Box<dyn FnOnce> doesn't respect self alignment #68304 for one specific instance)
• How can we mitigate the risk of unintended unsized or large allocas? Note that the problem already exists today with large structs/arrays. A MIR lint against large/variable stack sizes would probably help users avoid these stack overflows. Do we want it in Clippy? rustc?
• How do we handle truely-unsized DSTs when we get them? They can theoretically be passed to functions, but they can never be put in temporaries.
• Decide on a concrete syntax for VLAs.
• What about the interactions between async-await/generators and unsized locals?
• We currently allow extern type arguments with unsized_fn_params, but that does not make much sense and leads to ICEs: unsized_fn_params should not accept types that don't have a dynamically fixed size (such as extern types) #115709