Tracking issue for RFC #1909: Unsized Rvalues (unsized_locals, unsized_fn_params)

[aturon]

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

[Aaron1011]

How do we handle truely-unsized DSTs when we get them?

@aturon: Are you referring to extern type?

[aturon]

@Aaron1011 that was copied straight from the RFC. But yes, I presume that's what it's referring to.

[ldr709]

Why would unsized temporaries ever be necessary? The only way it would make sense to pass them as arguments would be by fat pointer, and I cannot think of a situation that would require the memory to be copied/moved. They cannot be assigned or returned from functions under the RFC. Unsized local variables could also be treated as pointers.

In other words, is there any reason why unsized temporary elision shouldn't be always guaranteed?

[F001]

Is there any progress on this issue?
I'm trying to implement VLA in the compiler. For the AST and HIR part, I added a new enum member for syntax::ast::ExprKind::Repeat and hir::Expr_::ExprRepeat to save the count expression as below:

enum RepeatSyntax { Dyn, None }
syntax::ast::ExprKind::Repeat(P<Expr>, P<Expr>, RepeatSyntax)

enum RepeatExprCount {
  Const(BodyId),
  Dyn(P<Expr>),
}
hir::Expr_::ExprRepeat(P<Expr>, RepeatExprCount)

But for the MIR part, I have no idea how to construct a correct MIR. Should I update the structure of mir::RValue::Repeat and corresponding trans_rvalue function? What should they look like? What is the expected LLVM-IR?

Thanks in advance if someone would like to write a simple mentoring instruction.

[qnighy]

I'm trying to remove the Sized bounds and translate MIRs accordingly.