Virtual locals scheme

[spastorino]

What is this issue?

This is a major change proposal, which means a proposal to make a notable change to the compiler -- one that either alters the architecture of some component, affects a lot of people, or makes a small but noticeable public change (e.g., adding a compiler flag). You can read more about the MCP process on https://forge.rust-lang.org/.

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.

MCP Checklist

• MCP filed. Automatically, as a result of filing this issue:
  • The @rust-lang/wg-prioritization group will add this to the triage meeting agenda so folks see it.
  • A Zulip topic in the stream #t-compiler/major changes will be created for this issue.
• MCP seconded. The MCP is "seconded" when a compiler team member or contributor issues the @rustbot second command. This should only be done by someone knowledgable with the area -- before seconding, it may be a good idea to cc other stakeholders as well and get their opinion.
• Final comment period (FCP). Once the MCP is approved, the FCP begins and lasts for 10 days. This is a time for other members to review and raise concerns -- concerns that should block acceptance should be noted as comments on the thread, ideally with a link to Zulip for further discussion.
• MCP Accepted. At the end of the FCP, a compiler team lead will review the comments and discussion and decide whether to accept the MCP.
  • At this point, the major-change-accepted label is added and the issue is closed. You can link to it for future reference.

A note on stability. If your change is proposing a new stable feature, such as a -C flag, then a full team checkoff will be required before the feature can be landed. Often it is better to start with an unstable flag, like a -Z flag, and then move to stabilize as a secondary step.

TL;DR

Right now, places in MIR can have an infinite number of projections. These projections contain not just offset projections like field, const index and downcast but also deref and index. We propose to eliminate place projections entirely, and instead have an Rvalue::Project for the static projections and custom Rvalues for the other projections.

Links and Details

This is work towards the eventual goal of removing entirely PlaceElem::Index. You can see the full proposal in this HackMD.

Mentors or Reviewers

@oli-obk
cc @nikomatsakis

[oli-obk]

@rustbot second

[nikomatsakis]

I am raising a formal concern -- before we move forward, we should resolve the discussion that @ecstatic-morse and I have been having about an alternative wherein we "lower" complex paths before starting to do optimizations.

[oli-obk]

Closing this proposal in favour of lowering projections after analyses like borrowck and before the regular optimization pipeline instead of doing deep modifications of the MIR that require changes to MIR building