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

async_closure: error: implementation of AsyncFnOnce is not general enough #126350

Open
Tracked by #110338
Jacherr opened this issue Jun 12, 2024 · 2 comments
Open
Tracked by #110338
Labels
A-async-await Area: Async & Await AsyncAwait-Triaged Async-await issues that have been triaged during a working group meeting. C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-types Relevant to the types team, which will review and decide on the PR/issue.

Comments

@Jacherr
Copy link
Contributor

Jacherr commented Jun 12, 2024

I'm not sure if this is really a bug (or perhaps a duplicate issue of another bug). However, I can't see any reason why this shouldn't work.

I tried this code:

#![feature(async_closure)]

fn assert_send<T: Send>(_: T) {}

#[derive(Clone)]
struct Ctxt<'a>(&'a ());

async fn commit_if_ok<'a>(ctxt: &mut Ctxt<'a>, f: impl async FnOnce(&mut Ctxt<'a>)) {
    f(&mut ctxt.clone()).await;
}

fn operation(mut ctxt: Ctxt<'_>) {
    assert_send(async {
        commit_if_ok(&mut ctxt, async |_| todo!()).await;
    });
}

fn main() {}

I expected to see this happen: Code compiles successfully

Instead, this happened: Compile error:

error: implementation of `AsyncFnOnce` is not general enough
  --> src/lib.rs:13:5
   |
13 | /     assert_send(async {
14 | |         commit_if_ok(&mut ctxt, async |_| todo!()).await;
15 | |     });
   | |______^ implementation of `AsyncFnOnce` is not general enough
   |
   = note: `{async closure@src/lib.rs:14:33: 14:42}` must implement `AsyncFnOnce<(&mut Ctxt<'1>,)>`, for any two lifetimes `'0` and `'1`...
   = note: ...but it actually implements `AsyncFnOnce<(&mut Ctxt<'_>,)>`

error: could not compile `playground` (lib) due to 1 previous error

(see https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=536db823e50d32307ee54645dbec25c6)

Meta

rustc --version --verbose:

rustc 1.80.0-nightly (032af18af 2024-06-02)
binary: rustc
commit-hash: 032af18af578f4283a2927fb43b90df2bbb72b67
commit-date: 2024-06-02
host: x86_64-unknown-linux-gnu
release: 1.80.0-nightly
LLVM version: 18.1.6

@Jacherr Jacherr added the C-bug Category: This is a bug. label Jun 12, 2024
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Jun 12, 2024
@compiler-errors compiler-errors self-assigned this Jun 12, 2024
@compiler-errors
Copy link
Member

actually this has nothing to do with async closures

this is one of many issues having to do with async, higher ranked bounds, and Send/Sync :( #110338

@compiler-errors compiler-errors removed their assignment Jun 12, 2024
@jieyouxu jieyouxu added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. A-async-await Area: Async & Await T-types Relevant to the types team, which will review and decide on the PR/issue. labels Jun 12, 2024
@saethlin saethlin removed the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Jul 5, 2024
@traviscross
Copy link
Contributor

@rustbot labels +AsyncAwait-Triaged

We discussed this in the async meeting today. As CE said, we think this is related to:

@rustbot rustbot added the AsyncAwait-Triaged Async-await issues that have been triaged during a working group meeting. label Jul 11, 2024
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 AsyncAwait-Triaged Async-await issues that have been triaged during a working group meeting. C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-types Relevant to the types team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

6 participants