[subhdotsol]

Closes #163137.

When an async block is passed where AsyncFnOnce() is expected, rustc currently reports a generic E0277 error without explaining how to fix the code.

For example:

fn main() {
    handler(async {});
}

fn handler(_f: impl AsyncFnOnce()) {}

Current Output

error[E0277]: the trait bound `{async block@src/main.rs:2:13: 2:18}: AsyncFnOnce()` is not satisfied
 --> src/main.rs:2:13
  |
2 |     handler(async {});
  |     ------- ^^^^^^^^ the trait `AsyncFnOnce()` is not implemented for `{async block@src/main.rs:2:13: 2:18}`
  |     |
  |     required by a bound introduced by this call
  |
note: required by a bound in `handler`
 --> src/main.rs:5:21
  |
5 | fn handler(_f: impl AsyncFnOnce()) {}
  |                     ^^^^^^^^^^^^^ required by this bound in `handler`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `playground` (bin "playground") due to 1 previous error

This change adds a targeted diagnostic for this case:

help: the trait `AsyncFnOnce()` is not implemented for `()`
note: wrap the `()` in a closure with no arguments: `async || { /* code */ }`

The diagnostic is only emitted when the failing type is an async block and the required trait is AsyncFnOnce.

A UI regression test was added for #163137.

Tests:

• ./x.py test tests/ui/async-await/async-closures/suggest-async-closure-issue-163137.rs --stage 1
• ./x.py test tests/ui/async-await/async-closures/suggest-async-block-issue-140265.rs --stage 1

[rustbot]

Thanks for the pull request, and welcome! The Rust Project has assigned @petrochenkov (or someone else) to review your changes, you should hear from them (or someone else) within the next two weeks.

Please see the contribution instructions and our LLM policy for more information.

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler, types
• compiler, types expanded to 77 candidates
• Random selection from 19 candidates

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[mejrs]

Please disclose whether a LLM was used to write this PR/description.

This should probably also be a rustc_on_unimplemented attribute (similar to what the regular Fn traits do) rather than be supported in this way. Is this possible?

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[subhdotsol]

@mejrs I did not use any LLM to write the PR or the description most of the description was based directly on the original issue

and regarding rustc_on_unimplemented, i am not sure about it, I'll investigate whether this can be expressed through the existing Fn/FnOnce approach , probably i will need help from the maintainers from it

[mejrs]

and regarding rustc_on_unimplemented, i am not sure about it, I'll investigate whether this can be expressed through the existing Fn/FnOnce approach , probably i will need help from the maintainers from it

Take a look at https://rustc-dev-guide.rust-lang.org/diagnostics.html#rustc_on_unimplemented . You can probably use the from_desugaring modifier here.

[subhdotsol]

@rustbot ready

[mejrs]

and regarding rustc_on_unimplemented, i am not sure about it, I'll investigate whether this can be expressed through the existing Fn/FnOnce approach , probably i will need help from the maintainers from it

I've taken a look and I'd prefer if this was done through the rustc_on_unimplemented attribute, not by adding this diagnostic code.

Can you add support for using "{async block}" in rustc_on_unimplemented? Take a look at #154118 for an example.

Then you can simply add #[rustc_on_unimplemented(on(Self = "{async block}", note = "...."))] on AsyncFnOnce.

@rustbot author

[mejrs]

r? me

[workingjubilee]

Why did you add that "Tests" list to your PR description, @subhdotsol?

Why does it name a test that was not diffed at all in this PR?

[subhdotsol]

@mejrs cool i will have a look and add support for "{async block}"

[mejrs]

I'm not sure how easy it would be to support parsing that with a space inbetween (happens in rustc_parse_format), using {async_block} is also an option.