Change:
The and documentation shows "notable traits" on the method, and any other methods that return a Pin or a Box: ! That's because these structs have "pass-through" implementations: if implements , then implements . If implements , then implements . Since returns , it gets the icon indicating a notable trait. These return types should not be annotated with the , since "notable traits" should be reserved for things that are actually notable - like the impl on . One way to achieve this: if the bounds for the impl include the "notable trait", don't consider that impl eligible for treatment.
Out of curiosity, I a to emit a list of which types get the "notable traits" annotation for which traits. Running this over std, emitting one line per instance, and going through , I get the below. For instance, shows up as a return type 183 times in the std docs, with a "notable trait" of iterator each time. The high count for iterator types is expected - it's because these get repeated on different pages for every item that implements Iterator. After the iterator types, slice's Read/Write impls and Box's Read/Write/Future/Iterator impls are the most frequent.
I got a PR implementing this solution, just need to clean it up. What's the best way to make a test for this? Just a regular rustdoc test?
Yep! Specifically one of the tests under src/test/rustdoc that generates documentation for a small example and then makes assertions on the output. Note that this is a bit of a tricky test since it's a negative assertion. So it would be easy for the test to pass but for unrelated reasons (for instance if we changed the HTML layout). To avoid that problem I recommend having two parts of the test, for two different items: one item that should have the annotation, and one item that should not have the annotation. That way if the HTML layout changes the test will fail.
any updates? BTW I think it would be reasonable to just special case "Box" and "Pin" by name and say they should never get the treatment.
Sorry, gotta rebase this, and I saw some weird regressions in the UI tests with this heuristic...
Ugh, sorry, probably won't get around to fixing this. I'll unclaim.

Discussion:
if let Some((did, ty)) = decl.output.as_return().and_then(|t| Some((t.def_id(cx.cache())?, t))) { <ins> // Box has pass-through impls for Read, Write, Iterator, and Future when the // boxed type implements one of those. We don't want to treat every Box return // as being notably an Iterator (etc), though, so we exempt it. Pin has the same // issue, with a pass-through impl for Future. if Some(did) == cx.tcx().lang_items().owned_box() || Some(did) == cx.tcx().lang_items().pin_type() { return "".to_string(); } </ins> if let Some(impls) = cx.cache().impls.get(&did) { for i in impls { let impl_ = i.inner_impl();

<ins> #![feature(doc_notable_trait)] #![feature(lang_items)] #![feature(no_core)] #![no_core] #[lang = "owned_box"] pub struct Box<T>; impl<T> Box<T> { pub fn new(x: T) -> Box<T> { Box } } #[doc(notable_trait)] pub trait FakeIterator {} impl<I: FakeIterator> FakeIterator for Box<I> {} #[lang = "pin"] pub struct Pin<T>; impl<T> Pin<T> { pub fn new(x: T) -> Pin<T> { Pin } } impl<I: FakeIterator> FakeIterator for Pin<I> {} // @!has doc_notable_trait_box_is_not_an_iterator/fn.foo.html '//*' 'Notable' pub fn foo<T>(x: T) -> Box<T> { Box::new(x) } // @!has doc_notable_trait_box_is_not_an_iterator/fn.bar.html '//*' 'Notable' pub fn bar<T>(x: T) -> Pin<T> { Pin::new(x) } </ins>