Desugar async blocks in HIR instead of MIR

[cjgillot]

Proposal

In the current implementation, gen/async/async gen blocks and closures have type Coroutine(..) and CoroutineClosure(..). Those types implement Iterator, Future or AsyncIterator depending on the initial desugaring.

This creates a lot of complexity:

• trait solvers must check which kind of coroutine each time;
• MIR StateTransform needs to fixup types depending on the coroutine kind.

I propose to change the desugaring for coroutines to:

• gen { .. } becomes CoroutineIterator::from_coroutine(#[coroutine] { .. });
• async { .. } becomes CoroutineFuture::from_coroutine(#[coroutine] { .. });
• async gen { .. } becomes CoroutineAsyncIterator::from_coroutine(#[coroutine] { .. }).

This way, all coroutines implement std::ops::Coroutine and core is responsible for translating this to user-friendly traits. All the complexity is pushed to error-reporting code, which is not soundness-critical.

Coroutine closures are a little more complex, as we need to keep the CoroutineClosure type for borrow-checking.

Mentors or Reviewers

This involves MIR manipulation and trait solving, so @oli-obk and @lcnr need to know.

Process

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

• File an issue describing the proposal.
• A compiler team member who is knowledgeable in the area can second by writing @rustbot second or kickoff a team FCP with @rfcbot fcp $RESOLUTION.
  • Refer to Proposals, Approvals and Stabilization docs for when a second is sufficient, or when a full team FCP is required.
• Once an MCP is seconded, the Final Comment Period begins.
  • Final Comment Period lasts for 10 days after all outstanding concerns are solved.
  • Outstanding concerns will block the Final Comment Period from finishing. Once all concerns are resolved, the 10 day countdown is restarted.
  • If no concerns are raised after 10 days since the resolution of the last outstanding concern, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Caution

Concerns (1 active)

• back-to-the-future

Managed by @rustbot—see help for details.

[rustbot]

Important

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.

Concerns or objections can formally be registered here by adding a comment.

@rustbot concern reason-for-concern
<description of the concern>

Concerns can be lifted with:

@rustbot resolve reason-for-concern

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler

[oli-obk]

@rustbot second

[oli-obk]

@rustbot concern back-to-the-future

Registering Ralf's concern. Should answer this before doing anything here.

Why was this changed and are we losing anything by moving back to the old way?