rustdoc: Trait implementors could show associated types as well

[alexcrichton]

For example there are many implementors of the Deref trait, but you have to follow through on the Self type to see what the associated types are.

Rustdoc may want to show associated type bindings there as well (but the clutter should be evaluated).

cc #21092, the original issue

[lilyball]

I'm strongly in favor of this. I didn't actually realize rustdoc was showing associated types in the list of traits for a concrete type, since I often look at the list of implementors for a specific trait instead.

A simple suggestion would be to use the inline shorthand notation, so e.g. core::ops::Index would say something like

impl<T> Index<usize, Output=T> for [T]
impl Index<Range<usize>, Output=str> for String

[Diggsey]

Additionally, with generic implementations there may not even be a Self type which can be viewed to see the associated types, eg.

impl<T> ToOwned for [T] where T: Clone

Presumably <[T] as ToOwned>::Owned == Vec<T>, but there's no way to tell that from the documentation, and it could just as well be Box<[T]>.

[jethrogb]

There's another problem similar to the one @Diggsey describes that this would resolve. If crate CA implements a trait with an associated type for a type TB from crate CB, you can't find out the associated type from the docs. The normal way would be to look at the documentation for TB, but that is not necessarily included with the CA documentation.

Example: impl Num for f64 etc.

[mitaa]

I guess a src-link for all-the-things impls would help here too. (#12932)

[jplatte]

This is also a problem in the futures crate, where there are IntoFuture impl's for tuples, e.g.

impl<A, B> IntoFuture for (A, B) where
    A: IntoFuture,
    B: IntoFuture<Error = A::Error>, 

In that case it would also be very helpful to show the impl blocks documentation on the trait page, which I didn't find an existing issue for. Without either piece of information, it is impossible to know whether this IntoFuture implementation will wait for both Futures to complete before completing itself, or have them race (except maybe that racing would be implemented for Future rather than IntoFuture, but that's far from obvious).

About the extra output potentially cluttering the doc page: What about having the extra information hidden by default, with one of those [+] expanders that we have all over rustdoc pages already?

[QuietMisdreavus]

I opened #43515 to fix this.