When needing type annotation do not suggest using `impl Trait` or closure

[estebank]

Subset of #63502

When encountering

#![feature(async_await)]

use std::io::Error;

fn make_unit() -> Result<(), Error> { 
    Ok(())
}

fn main() {
    let fut = async {
        make_unit()?;
        
        Ok(())
    };
}

Do not suggest "consider giving fut the explicit type impl std::future::Future, with the type parameters specified ", as introduced in #61361, when encountering impl Trait:

rust/src/librustc/infer/error_reporting/need_type_info.rs

Lines 140 to 169 in 60960a2

	// When `name` corresponds to a type argument, show the path of the full type we're
	// trying to infer. In the following example, `ty_msg` contains
	// " in `std::result::Result<i32, E>`":
	// ```
	// error[E0282]: type annotations needed for `std::result::Result<i32, E>`
	// --> file.rs:L:CC
	// |
	// L | let b = Ok(4);
	// | - ^^ cannot infer type for `E` in `std::result::Result<i32, E>`
	// | |
	// | consider giving `b` the explicit type `std::result::Result<i32, E>`, where
	// | the type parameter `E` is specified
	// ```
	let (ty_msg, suffix) = match &local_visitor.found_ty {
	Some(ty) if &ty.to_string() != "_" && name == "_" => {
	let ty = ty_to_string(ty);
	(format!(" for `{}`", ty),
	format!("the explicit type `{}`, with the type parameters specified", ty))
	}
	Some(ty) if &ty.to_string() != "_" && ty.to_string() != name => {
	let ty = ty_to_string(ty);
	(format!(" for `{}`", ty),
	format!(
	"the explicit type `{}`, where the type parameter `{}` is specified",
	ty,
	name,
	))
	}
	_ => (String::new(), "a type".to_owned()),
	};

Also, the case for closures (CC #46680):

error[E0282]: type annotations needed for `[closure@src/main.rs:3:13: 6:6]`
 --> src/main.rs:4:9
  |
3 |     let x = || {
  |         - consider giving `x` the explicit type `[closure@src/main.rs:3:13: 6:6]`, with the type parameters specified
4 |         Err(())?;
  |         ^^^^^^^^ cannot infer type

[Centril]

Btw, when we have the ability to ascribe a type let fut: impl Trait = async { ... }; then it does seem reasonable to suggest it again, so we should open an issue for undoing the fix to this issue.

[estebank]

then it does seem reasonable to suggest it again

Indeed, but suggestions should only be provided when they can be applied, either gated on nightly or not provided at all if depending on nightly features.