Tracking Issue for removing unsized_locals

[Noratrieb]

This is a tracking issue for the MCP "630" (rust-lang/compiler-team#630).
The feature gate for the issue is #![feature(unsized_locals)].

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implement the MCP (cc @rust-lang/compiler-contributors -- can anyone write up mentoring
  instructions?)
• Adjust documentation ([see instructions on rustc-dev-guide][doc-guide])

Implementation history

[Jules-Bertholet]

It seems strange to see this happen so soon after the major soundness issue with this feature was fixed (#111374).

[RalfJung]

FWIW, in #114483 I managed to find a nice way to unify the handling of sized and unsized function parameters. However, unsized locals still don't work.

Fundamentally, the problem is that StorageLive should allocate the memory for a local -- but for unsized locals, it cannot know how much memory that is. The new primitive that helped in #114483 is a storage_live_dyn that is given pointer metadata to compute the size for dynamically sized types. So I think to add unsized locals to MIR in a proper way, we'd want to extend StorageLive with an (optional) parameter that indicates another, existing place that has the same type as the local, and whose metadata is used for the assignment.

The source-level assignment x = y; could then be compiled to

StorageLive(x, y);
x = y;

and that would be a coherent way to represent dynamically sized locals in MIR without weird hacks like we needed them in the past.

In LLVM codegen, the StorageLive would compile to an alloca; assignment could be a regular memcpy (but needs to compute the dynamic size of course).