Diagnostics request: suggest a closure with an async block when an async closure is encountered

[jebrosen]

Consider the following code (playground):

use std::future::Future;

async fn wants_closure_returning_future<F, Fut, R>(f: F) -> R
where
    F: FnOnce() -> Fut,
    Fut: Future<Output=R>,
{
    f().await
}

fn main() {
    // error[E0658]: async closures are unstable
    let fut1 = wants_closure_returning_future(async || 3);
    
    // Fine, and what should have been used anyway
    let fut2 = wants_closure_returning_future(|| async { 3 });
}

With the following output:

error[E0658]: async closures are unstable
  --> src/main.rs:13:47
   |
13 |     let fut1 = wants_closure_returning_future(async || 3);
   |                                               ^^^^^
   |
   = note: see issue #62290 <https://github.com/rust-lang/rust/issues/62290> for more information

In many cases moving the async keyword fixes the error and is "good enough" despite the differences in semantics, so it would be nice if the compiler could suggest this as well:

  = help: try returning a future instead: `|| async { 3 }`

This is also easy to run into when using futures or stream combinators such as then, especially for someone who is not yet very familiar with async/await.

[Ugator]

Why does a compiler hint to not use an unstable feature depend on that unstable feature to be stabilized? It seems to me that the design pattern of "luring people into unstable" is questionable anyways, so when we can suggest an alternative that should have priority over hinting towards unstable.

[compiler-errors]

I don't believe it makes sense to suggest not using async ||. They now materially behave differently after #120361.