Include type bindings on string representation of `impl Trait`

[estebank]

Follow up to #63507 (comment)

Include type arguments for traits when displaying impl Trait. For example, the following:

error[E0282]: type annotations needed for `impl std::future::Future`
  --> $DIR/cannot-infer-async-enabled-impl-trait-bindings.rs:14:9
   |
LL |     let fut = async {
   |         --- consider giving `fut` the explicit type `impl std::future::Future`, with the type parameters specified
LL |         make_unit()?;
   |         ^^^^^^^^^^^^ cannot infer type

should be

error[E0282]: type annotations needed for `impl std::future::Future`
  --> $DIR/cannot-infer-async-enabled-impl-trait-bindings.rs:14:9
   |
LL |     let fut = async {
   |         --- consider giving `fut` the explicit type `impl std::future::Future<Output=_>`, with the type parameters specified
LL |         make_unit()?;
   |         ^^^^^^^^^^^^ cannot infer type

[iluuu1994]

@rustbot claim

Should have time tonight. 🙂

[iluuu1994]

I'll probably better wait until #63507 is merged 😊

[estebank]

@iluuu1994 that should happen sometime today.

[iluuu1994]

@estebank Would you mind giving me a few pointers? I looked through the source code but it wasn't completely obvious to me on how to achieve this. Is this already supported by the FmtPrinter or something new that has to be implemented?

[estebank]

I'm not sure if this codepath is using FmtPrinter (I did a quick check changing this to "im pl " and I didn't see any change to this error. I think that what you want to look at is

rust/src/librustc/ty/print/mod.rs

Lines 212 to 255 in afc39bb

	fn default_print_impl_path(
	self,
	impl_def_id: DefId,
	_substs: &'tcx [Kind<'tcx>],
	self_ty: Ty<'tcx>,
	impl_trait_ref: Option<ty::TraitRef<'tcx>>,
	) -> Result<Self::Path, Self::Error> {
	debug!("default_print_impl_path: impl_def_id={:?}, self_ty={}, impl_trait_ref={:?}",
	impl_def_id, self_ty, impl_trait_ref);
	let key = self.tcx().def_key(impl_def_id);
	let parent_def_id = DefId { index: key.parent.unwrap(), ..impl_def_id };
	// Decide whether to print the parent path for the impl.
	// Logically, since impls are global, it's never needed, but
	// users may find it useful. Currently, we omit the parent if
	// the impl is either in the same module as the self-type or
	// as the trait.
	let in_self_mod = match characteristic_def_id_of_type(self_ty) {
	None => false,
	Some(ty_def_id) => self.tcx().parent(ty_def_id) == Some(parent_def_id),
	};
	let in_trait_mod = match impl_trait_ref {
	None => false,
	Some(trait_ref) => self.tcx().parent(trait_ref.def_id) == Some(parent_def_id),
	};
	if !in_self_mod && !in_trait_mod {
	// If the impl is not co-located with either self-type or
	// trait-type, then fallback to a format that identifies
	// the module more clearly.
	self.path_append_impl(
	|cx| cx.print_def_path(parent_def_id, &[]),
	&key.disambiguated_data,
	self_ty,
	impl_trait_ref,
	)
	} else {
	// Otherwise, try to give a good form that would be valid language
	// syntax. Preferably using associated item notation.
	self.path_qualified(self_ty, impl_trait_ref)
	}
	}
	}

and make it use the _substs, but again, I'm not 100% sure that is the case.

[iluuu1994]

I will try that, thanks @estebank 🙂