More friendly error msg when await on NONE ASYNC fn/block or return a obj that implements deprecated Future

[CGQAQ]

fn bar () -> impl futures::future::Future<Item=(), Error=()> {}

fn boo (){}

async fn foo() -> std::io::Result<()> {
    boo().await;
    bar().await;
    std::io::Result::Ok(())
}

error[E0277]: the trait bound `(): std::future::Future` is not satisfied
   --> src/main.rs:6:5
    |
6   |     boo().await;
    |     ^^^^^^^^^^^ the trait `std::future::Future` is not implemented for `()`

error[E0277]: the trait bound `impl futures::future::Future: std::future::Future` is not satisfied
   --> src/main.rs:7:5
    |
7   |     bar().await;
    |     ^^^^^^^^^^^ the trait `std::future::Future` is not implemented for `impl futures::future::Future`

error: aborting due to 2 previous errors

1. First error should more likeawait need a async function, async block or return a type that impl std::future::Future, did you forget add async before fn boo() ?
2. Second error should more like You are return a Future that has been droped support or deprecated, maybe try to upgrade to latest version of futures crate?
3. if 3rd party crate depends on derpecated crate that uses deprecated Future trait, the compiler should also tell use explicitly by some error message. (e.g. reqwest 0.9.22 depends on futures = "0.1.23")

I think more friendly error message like these will help new comers from javascript -> front end devs to more quickly solve problem, because they don't have multiple Promise implements, current error messages will make them very confusing and frustrating

[estebank]

After #66651 is merged, adding a rustc_on_unimplemented message on std::future::Future with these two cases will be trivial.

[basil-cow]

@estebank I don't think it will, enclosing_scope lets you add a message to the foo function, not bar or boo.

[nikomatsakis]

Handling the second case (a future from some older version of the futures crate) doesn't seem worth the effort. I think those will vanish over time. Handling the case like boo().await seems worthwhile.

[nikomatsakis]

Marking as "on-deck", I think that helping people identify cases where they put .await on something that is not a future seems pretty good.

[nikomatsakis]

One note: I'm not sure if "on unimplemented" is the right implementation approach. Ideally, we would suggest that the user make fn boo an async fn boo. To do that, we'd want to look for cases like <function-call>.await. I'm not sure what it would take to identify such a case, we might be able to detect it in type-check and thread in a special "obligation cause" so that we can give a more targeted hint. (But the desugaring may also get in the way here.)

[estebank]

CC #61076