[WIP] 'Notable Trait Implementations' doc section

[conradludgate]

Adds a 'Notable Trait Implementations' section to type pages, in a similar layout to 'Deref Implementations'

Dependant on #94904

Reasoning: #45040 (comment)

[rust-highfive]

r? @GuillaumeGomez

(rust-highfive has picked a reviewer for you, use r? to override)

[conradludgate]

I think before this gets merged in, we need to figure out a way to stop Box from having some redundant notability, and to formalise that

[bors]

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

[Antikyth]

I think before this gets merged in, we need to figure out a way to stop Box from having some redundant notability, and to formalise that

I'm not sure if this is along the lines you were thinking, but would some kind of attribute that can 'override foreign notability' be appropriate? Pretty much a way to say "I am a Box and I don't accept your judgement on notability", if you get what I mean :)

Perhaps that could work with notable on trait implementations in that those could act as a whitelist? I haven't really considered the exact implications of that.

Pseudocode for example, but I have no idea what I'm doing so don't take this as a complete suggestion or anything:

#[stable(feature = "rust1", since = "1.0.0")]
#[doc(override_notability)]
pub struct Box<
    T: ?Sized,
    #[unstable(feature = "allocator_api", issue = "32838")] A: Allocator = Global,
>(Unique<T>, A);

[Dylan-DPC]

marking it as blocked on #94904

[notriddle]

I don't support this PR as-is. The doc(notable) feature should attach (i) callouts to return types, and not do anything else.

• If we reserve the right to change the attribute's behavior after stablizing it, we're going to have to teach everyone what the tag means instead of what it does, and that's historically been very difficult to do. The design principle I have in mind is that the semantic web was kind of a failure, people are going to write presentational markup even if we ask them not to, and we should design rustdoc so doing that isn't harmful.

• It's true that std::iter::Map is a case where you want the notable trait to be at the top of the trait implementations list and in the (i) callout, but Box is an example where you only want one of these behaviors. If some function returns a Box<std::iter::Map>, the Iterator trait is definitely notable, even though Iterator shouldn't be shown as notable on Box's home page.

• Notableness is situational. As the feature currently exists, it documents traits that are "notable" if you call a function that returns it. Notable traits aren't mentioned for function parameters, because the use case is so different. For example, functions that accept T where T: AsRef<Path> often point out that str implements this trait in their docs — we could say that the impl AsRef<Path> for str is a notable implementation for parameters passing, even though we wouldn't want to mention Path on every function that returns a str.

[GuillaumeGomez]

This PR seems blocked for now so I'm closing it. Please don't hesitate to reopen it or open a new one if you want to give a try at tackling this issue again!