Using try operator on a future doesn't suggest to .await it

[coolreader18]

Given the following code: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=b539ebe10f181c1f2b245a021684dff1

use std::future::Future;

async fn foo() -> Result<(), i32> {
    func(async { Ok::<_, i32>(()) })?;
    
    Ok(())
}

async fn func<T>(fut: impl Future<Output = T>) -> T {
    fut.await
}

The current output is:

Compiling playground v0.0.1 (/playground)
error[[E0277]](https://doc.rust-lang.org/stable/error-index.html#E0277): the `?` operator can only be applied to values that implement `Try`
 --> src/lib.rs:4:5
  |
4 |     func(async { Ok::<_, i32>(()) })?;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the `?` operator cannot be applied to type `impl Future<Output = Result<(), i32>>`
  |
  = help: the trait `Try` is not implemented for `impl Future<Output = Result<(), i32>>`

For more information about this error, try `rustc --explain E0277`.

Ideally the output should look like:

Compiling playground v0.0.1 (/playground)
error[[E0277]](https://doc.rust-lang.org/stable/error-index.html#E0277): the `?` operator can only be applied to values that implement `Try`
 --> src/lib.rs:4:5
  |
4 |     func(async { Ok::<_, i32>(()) })?;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the `?` operator cannot be applied to type `impl Future<Output = Result<(), i32>>`
  |
  = help: try adding `.await` or something
 --> src/lib.rs:4:5
  |
4 |     func(async { Ok::<_, i32>(()) }).await?;
  |                                     ++++++
  |

For more information about this error, try `rustc --explain E0277`.

[coolreader18]

Huh, looks like this is a case where suggest_await_before_try doesn't kick in for some reason.

[coolreader18]

Ah, it's that the impl Future return type of an async function like this has HAS_TY_INFER. I don't know enough about rustc's typechecking to know whether this can be resolved haha.

[coolreader18]

It doesn't seem like the problem that caused #72766 is a thing anymore? I can remove the if self_ty.has_infer_types() { return } condition and it doesn't ICE on the example given in that issue.

[coolreader18]

@JohnTitor do you know if stuff has changed such that #72775 is no longer necessary?

[compiler-errors]

@coolreader18 I actually have a PR almost up that does just exactly that, though if you want to put one up instead then feel free.

[compiler-errors]

I'm pretty sure #86901 fixes this underlying issue. This method could use some additional cleanup as well.