Tracking issue for more precise coroutine captures

[tmandry]

Today, valid programs using coroutines (and async/await) are rejected by the compiler because it thinks certain values may be held across yields when they are not.

Examples / to do: (please add more as they come up)

• async/await: awaiting inside a match block captures borrow too eagerly #57017
• Dropped variables still included in generator type #57478
• Indexing via index method and [idx] sugar works differently in async blocks/functions  #72956
• ICE: Broken MIR #72651
• The rules for how non-Send local variables "infect" an async function, making its Future type non-Send also, are stricter than they need to be. #63768
• Moved value is considered as held across an await in async fn #87309
• Future non-Send although non-Send local is dropped before .await #104883

Unresolved Questions

How should we implement this?

Are there any programs which could be accepted, but shouldn't be because they would depend too heavily on implementation details of the compiler?

Implementation notes

There's some discussion here: #57017 (comment)

This issue has been assigned to @eholk via this comment.

[tmandry]

cc @nikomatsakis @Aaron1011

I've created a "meta-issue" to track these improvements.

[jonas-schievink]

I've removed #69672 and moved it over to #69826

[tmandry]

@rustbot assign @eholk

[eholk]

I think #94067 counts as another instance of this bug.

[oxalica]

Is this issue also tracking the case where the reference to the local Send is actually used after await point? I failed to come up a way to make the following code cause UB.

struct SendButNotSync(std::cell::RefCell<String>);

async fn work() {}

fn more_work(owned: SendButNotSync) -> impl std::future::Future<Output = ()> + Send {
    async move {
        // Keeps a reference of `owned`.
        let borrowed = owned.0.borrow();
        // During the context switch, no one can mutate either `owned` or `borrowed`.
        work().await;
        // Regain `owned` and `borrowed` BOTH on the same but possibly another thread.
        println!("{borrowed}");
    }
}

I can imagine that during await, the self-reference is pretended to be dropped but magically reborrowed from borrowed after resumed (derived from Pin<&mut Self> of Generator::resume in desugared form). In both before and after the await point, the borrowed is access in the same thread as owned, and no other thread could alter them in the same time.

[thebluetropics]

Will the issue soon be fixed? I am really hoping on this one