Hovering over a trait method should tell the trait

[jonas-schievink]

It would be useful if, instead of just listing the self type alloc::vec::Vec, this included as AsRef<[u8]> to make it easier to tell where the method comes from.

[ChayimFriedman2]

The return type is wrong here; I wonder why?

[flodiebold]

@ChayimFriedman2 We resolve the call to the wrong impl, which is not really a surprise because lookup_impl_method only takes a TraitId, not a TraitRef. It should take a TraitRef and then actually make sure the impls it looks at match that. That's a separate bug though.

As to the original bug, I think that actually was also introduced when we added going to the specific impl. In cases where we don't have a concrete impl, we do show the trait. We might want to show the full impl line (impl<T, A: Allocator> AsRef<Vec<T, A>> for Vec<T, A>) if we point to an impl.

[ChayimFriedman2]

What is preferred, to show the impl line (that doesn't show the substitutions) or Type as Trait? Each one has advantages and disadvantges.

[Veykril]

I feel like impls can have a lot of noise, where clauses, bounds etc which can get quite huge. That's too much information that isn't really necessary imo. I think rendering an as Trait at the end of the path as proposed initially shows the releveant part here?

[ChayimFriedman2]

We can show only impl<generics> type for trait, not the full impl.

[Veykril]

Ye I guess that would be good as well

[flodiebold]

We show the bounds from the function itself, so IMO it makes sense to also show the bounds of the impl. Maybe not in the first line though...

[Veykril]

The first line should definitely stay clear of bounds I think, we can see how it looks if we render them afterwards with a leading where and some indentation maybe. It might work out better than I anticipated