Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for more precise coroutine captures #69663

Open
5 of 7 tasks
tmandry opened this issue Mar 3, 2020 · 6 comments
Open
5 of 7 tasks

Tracking issue for more precise coroutine captures #69663

tmandry opened this issue Mar 3, 2020 · 6 comments
Assignees
Labels
A-async-await Area: Async & Await A-coroutines Area: Coroutines A-typesystem Area: The type system AsyncAwait-Triaged Async-await issues that have been triaged during a working group meeting. C-enhancement Category: An issue proposing an enhancement or a PR with one. E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@tmandry
Copy link
Member

tmandry commented Mar 3, 2020

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.

@tmandry tmandry added the C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. label Mar 3, 2020
@tmandry
Copy link
Member Author

tmandry commented Mar 3, 2020

cc @nikomatsakis @Aaron1011

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

@tmandry tmandry added C-enhancement Category: An issue proposing an enhancement or a PR with one. A-async-await Area: Async & Await A-coroutines Area: Coroutines E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. and removed C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. labels Mar 3, 2020
@tmandry tmandry added the AsyncAwait-Triaged Async-await issues that have been triaged during a working group meeting. label Mar 3, 2020
@jonas-schievink jonas-schievink added the A-typesystem Area: The type system label Mar 7, 2020
@jonas-schievink
Copy link
Contributor

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

@tmandry
Copy link
Member Author

tmandry commented Jul 16, 2021

@rustbot assign @eholk

@rustbot rustbot self-assigned this Jul 16, 2021
jakubdabek added a commit to jakubdabek/Rocket that referenced this issue Aug 21, 2021
This commit implements a workaround for an [issue within rustc].
The problem showed itself when using e.g. a `Vec<&str>` argument
in an async route handler (but not `&str`), which resulted in a
"implementation of `FromForm` is not general enough" error.
The workaround itself works by gathering all invocations of
`FromForm`'s methods inside a block without any `.await` points [ref].

[issue within rustc]: rust-lang/rust#69663
[ref]: rust-lang/rust#57478 (comment)
jakubdabek added a commit to jakubdabek/Rocket that referenced this issue Aug 21, 2021
This commit implements a workaround for an [issue within rustc].
The problem showed itself when using e.g. a `Vec<&str>` argument
in an async route handler (but not `&str`), which resulted in a
"implementation of `FromForm` is not general enough" error.
The workaround itself works by gathering all invocations of
`FromForm`'s methods inside a block without any `.await` points [ref].

[issue within rustc]: rust-lang/rust#69663
[ref]: rust-lang/rust#57478 (comment)
SergioBenitez pushed a commit to rwf2/Rocket that referenced this issue Aug 25, 2021
This commit implements a workaround for an [issue within rustc]. The
problem showed itself when using e.g. a `Vec<&str>` argument in an async
route handler (but not `&str`), which resulted in a "implementation of
`FromForm` is not general enough" error. The workaround itself works by
gathering all invocations of `FromForm`'s methods inside a block without
any `.await` points [ref].

[issue within rustc]: rust-lang/rust#69663
[ref]: rust-lang/rust#57478 (comment)
@eholk
Copy link
Contributor

eholk commented Feb 16, 2022

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

@oxalica
Copy link
Contributor

oxalica commented Jun 15, 2023

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.

@traviscross traviscross changed the title Tracking issue for more precise generator captures Tracking issue for more precise coroutine captures Jan 9, 2024
@thebluetropics
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-async-await Area: Async & Await A-coroutines Area: Coroutines A-typesystem Area: The type system AsyncAwait-Triaged Async-await issues that have been triaged during a working group meeting. C-enhancement Category: An issue proposing an enhancement or a PR with one. E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
Status: On deck
Development

No branches or pull requests

6 participants