Unify generation of primitive links for associated types with the rest

[GuillaumeGomez]

It is very weird to have this display:

Where you have &Rhs actually linking to the reference primitive. I think it'd be better to unify the behaviour with the other items (non-generics ones).

For some history, it was changed this way in #107244 to prevent having some symbols linking to different pages than the item following them.

It now looks like this:

r? @notriddle

[GuillaumeGomez]

Updated existing tests.

[GuillaumeGomez]

Correctly updated this time...

[notriddle]

This PR is removing a lot of links, and it results in array links that look like this:

&'static [T; 1]

That link is pretty hard to click, and its label is not very informative. I know you could get it to come up that way before, too, but if we're going to change these links again, I'd like to improve it by trying not to generate poor quality link text and link visualization.

[GuillaumeGomez]

Good point. I'll remove this last link as well then.

[GuillaumeGomez]

Removed link generation for arrays.

[bors]

☔ The latest upstream changes (presumably #114130) made this pull request unmergeable. Please resolve the merge conflicts.

[GuillaumeGomez]

Fixed merge conflict.

[notriddle]

I agree that this is weird, but previous discussions have shown that links to the slice and array pages, at least, are helpful (especially as “on-ramps”)

#98069 (comment)

It looks like this change removes all of the links to primitive.slice.html from function signatures. I’m not sure that’s a good idea.

[GuillaumeGomez]

I improved the current handling. You can test it here. I also updated the screenshot. So in short, I improved display of slice links and the reference links don't include the generic anymore.

[bors]

☔ The latest upstream changes (presumably #114905) made this pull request unmergeable. Please resolve the merge conflicts.

[GuillaumeGomez]

Fixed merge conflict.

[notriddle]

The sample docs at https://rustdoc.crud.net/imperio/generics-display/foo/trait.Trait.html still have a reference link, &Rhs, with a single-character link. That's not a large enough click target.

They also have *const Struct, a pair of links to different targets smashed together with no ability to tell there's more than one link. That's not user-friendly.

[GuillaumeGomez]

The sample docs at https://rustdoc.crud.net/imperio/generics-display/foo/trait.Trait.html still have a reference link, &Rhs, with a single-character link. That's not a large enough click target.

That's what I originally wanted to fix. It was bugging me that Rhs was included in the link. I can make the link bigger though (with padding). Could be an interesting lead to experiment.

They also have *const Struct, a pair of links to different targets smashed together with no ability to tell there's more than one link. That's not user-friendly.

I think the problem here is that both links have the same color. They are different types and link to different items, therefore they should not point to the same page.

[GuillaumeGomez]

One thing I thought that could improve greatly the situation for *const struct would be to add underline on hover on the links. What do you think?

[notriddle]

It was bugging me that Rhs was included in the link. I can make the link bigger though (with padding). Could be an interesting lead to experiment.

That would help with the click target problem. I’m not sure how to keep it from breaking the monospaced grid and looking weird.

underline on hover on the links

Underlines won’t be helpful on touch, and even with a mouse it’s not great to rely on that.

I honestly feel kind of trapped here, because all of the options I can think of have serious downsides.

• Back-to-back links that can only be distinguished by underlines are a discoverability problem, and can be frustrating if you wind up clicking the wrong thing because you don’t realize they’re separate.
• Giving them both different colors is a distracting UI. We used to do that, and it caused problems.
• Not coloring the *const part at all while still making it a link would also not be discoverable.
• Removing the link entirely makes it harder to discover the primitive page.
• Adding a setup where these are both one link, and clicking it brings up a popover asking if you want to go to the struct Foo page or the primitive pointer page would add friction for power users, who are going to want the struct page almost every time.
• Making struct Foo the only inline link, while making primitive pointer off to the side in an (i) popover, makes it less useful as a teaching aid for anyone who didn’t already know what *const meant.
• Linking only the star, as in *const Struct, is not a solution that can generalize to shared references, and it adds a one-character click target.
• Generating different links for generic and concrete types is inconsistent, and including the generic parameter name in the link text can be misleading. (I think that is why you opened this PR to begin with? Correct me if I’m wrong.)

[bors]

☔ The latest upstream changes (presumably #116230) made this pull request unmergeable. Please resolve the merge conflicts.

[tranquillity-codes]

Ping from triage, @GuillaumeGomez any updates on resolving the conflicts? Thanks!