Unimplement `unsized_locals`

[JakobDegen]

Proposal

Remove support from the compiler for the unsized_locals feature. The implementation of this feature cannot really be said to be "working" for any reasonable definition of the term:

1. The logic in codegen responsible for handling the implementation is known to be unsound around alignment - this unsoundness is pretty serious, and has existed for a while.
2. Const eval does not implement unsized locals and ICEs in cases where there are attempts to use them.
3. I have not really checked, but I expect Mir opts to be broadly wrong/broken in the presence of unsized locals. This is likely because:
4. We have no semantics (tentative or otherwise) for unsized locals in Mir. The ones that const eval used to implement - before support was removed - were known to be awkward and surprising.

I cannot imagine that we would accept the current implementation of unsized locals if it was submitted as a PR.

Note that the unsized_fn_params feature will be broadly unaffected. It is worth noting though that #111330 discovered that some parts of the unsized_fn_params feature cannot be implemented today without unsized locals support. I claim that that should not be a blocker for this change though. The fact that a supposedly less buggy feature depends on a broken feature to "work" just means that the less buggy feature is more buggy than we thought. It is not a good reason to keep the broken code around.

Mentors or Reviewers

Will mostly just involve deleting code, but maybe @oli-obk ?

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

cc @rust-lang/compiler @rust-lang/compiler-contributors

[oli-obk]

@rustbot second

[apiraino]

@rustbot label -final-comment-period +major-change-accepted