Tracking issue for more precise coroutine captures

@eholk

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)

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.

@nikomatsakis

cc @nikomatsakis @Aaron1011

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

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

@rustbot

@rustbot assign @eholk

Fix codegen issue for parameters with lifetimes

Workaround 'rustc' bug, compiling more async code.

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

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.

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

Another issue to be added to the list: #128095 (appears similar to #63768, but I'm not familiar enough with the internals to say for certain)

Navigation Menu

Repository navigation

Tracking issue for more precise coroutine captures #69663

Unresolved Questions

Implementation notes

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking issue for more precise coroutine captures #69663

Description

Unresolved Questions

Implementation notes

Activity

tmandry commented on Mar 3, 2020

jonas-schievink commented on Mar 8, 2020

tmandry commented on Jul 16, 2021

eholk commented on Feb 16, 2022

oxalica commented on Jun 15, 2023

thebluetropics commented on Jan 13, 2024

Xiretza commented on Jul 21, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions