RFC 2229 implementation plan

[nikomatsakis]

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

What follows is an implementation plan for RFC 2229, which reworks closures to capture places and not individual variables. This should result in better borrow check interactions.

• We will rewrite code that currently iterates over the "upvars" of a closure to iterate over a set of "places" produced by type-check.
  • The factorings below are steps in this direciton.
• We will adjust the existing upvar inference for closures. Today, when it sees (say) a read of a.b.c, it tracks that down to a shared borrow of a. But the new mode inference will be coallescing into a minimal set of [HIR places] that are accessed (e.g., if a.b.c and a.b are both read, then we would just capture a.b).
• We will have to rewrite the HAIR and MIR lowering so that a.b.c is rewritten to use the minimal place instead of always being relative to an upvar a.
  • The generated MIR that used to capture variables like a when constructing a closure will now capture the place (e.g., a.b.c)
• The only changes required in borrow check (afaik) are related to error reporting

Full details of the plan can be seen in this hackmd.

Links and Details

Add a few paragraphs explaining your design. The level of detail should be
sufficient for someone familiar with the compiler to understand what you're
proposing. Where possible, linking to relevant issues, old PRs, or external
documents like LLVM pages etc is very useful.

Mentors or Reviewers

nikomatsakis will mentor.

The work will be undertaken in the WG-RFC-2229 working group, but @blitzerr, Aman Arora and Chris Pardy are interesting in working on it.

It would be great to have one additional compiler team contributor/member interested in co-leading this effort!

[matthewjasper]

@rfcbot second

I would be happy to help with this.

[LeSeulArtichaut]

@matthewjasper I think the command is @rustbot second

[matthewjasper]

@rustbot second

[nikomatsakis]

Closing, this is accepted.