-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rustdoc: notable traits triggers on smart pointers #100320
Comments
Out of curiosity, I added a 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. @jsha: 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. |
@compiler-errors 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. |
…meGomez rustdoc: don't mark Box<T> as Iterator, Read, etc Because Box<T> has pass-through implementations, rustdoc was giving it the "Notable Traits" treatment for Iterator, Read, Write, and Future, even when the type of T was unspecified. Pin had the same problem, but just for Future. Fixes rust-lang#100320
…meGomez rustdoc: don't mark Box<T> as Iterator, Read, etc Because Box<T> has pass-through implementations, rustdoc was giving it the "Notable Traits" treatment for Iterator, Read, Write, and Future, even when the type of T was unspecified. Pin had the same problem, but just for Future. Fixes rust-lang#100320
The
Pin
andBox
documentation shows "notable traits" on thenew()
method, and any other methods that return a Pin or a Box:https://doc.rust-lang.org/nightly/std/boxed/struct.Box.html#method.new
https://doc.rust-lang.org/nightly/std/pin/struct.Pin.html#method.new
That's because these structs have "pass-through" implementations: if
T
implementsIterator
, thenBox<T>
implementsIterator
. IfT
implementsRead
, thenBox<T>
implementsRead
. Sincenew()
returnsBox<T>
, 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
Iterator
impl onstd::slice::Iter
.One way to achieve this: if the
where
bounds for the impl include the "notable trait", don't consider that impl eligible for ⓘ treatment.The text was updated successfully, but these errors were encountered: