Change:
<ins> // Regression test for issues #77763, #84579 and #102142. #![crate_name = "main"] // aux-build:assoc_item_trait_bounds_with_bindings.rs // build-aux-docs // ignore-cross-compile extern crate assoc_item_trait_bounds_with_bindings as aux; // FIXME(fmease): Don't render an incorrect `T: ?Sized` where-clause for parameters //                of GATs like `Main::Out{2,4}`. Add a snapshot test once it's fixed. // FIXME(fmease): Print the `for<>` parameter list in the bounds of //                `Main::Out{6,11,12}`. // @has main/trait.Main.html // @has - '//*[@id="associatedtype.Out0"]' 'type Out0: Support<Item = ()>' // @has - '//*[@id="associatedtype.Out1"]' 'type Out1: Support<Item = Self::Item>' // @has - '//*[@id="associatedtype.Out2"]' 'type Out2<T>: Support<Item = T>' // @has - '//*[@id="associatedtype.Out3"]' 'type Out3: Support<Produce<()> = bool>' // @has - '//*[@id="associatedtype.Out4"]' 'type Out4<T>: Support<Produce<T> = T>' // @has - '//*[@id="associatedtype.Out5"]' "type Out5: Support<Output<'static> = &'static ()>" // @has - '//*[@id="associatedtype.Out6"]' "type Out6: Support<Output<'a> = &'a ()>" // @has - '//*[@id="associatedtype.Out7"]' "type Out7: Support<Item = String, Produce<i32> = u32> + Unrelated" // @has - '//*[@id="associatedtype.Out8"]' "type Out8: Unrelated + Protocol<i16, Q1 = u128, Q0 = ()>" // @has - '//*[@id="associatedtype.Out9"]' "type Out9: FnMut(i32) -> bool + Clone" // @has - '//*[@id="associatedtype.Out10"]' "type Out10<'q>: Support<Output<'q> = ()>" // @has - '//*[@id="associatedtype.Out11"]' "type Out11: Helper<A<'s> = &'s (), B<'r> = ()>" // @has - '//*[@id="associatedtype.Out12"]' "type Out12: Helper<B<'w> = Cow<'w, str>, A<'w> = bool>" // // Snapshots: Check that we do not render any where-clauses for those associated types since all of // the trait bounds contained within were moved to the bounds of the respective item. // // @snapshot out0 - '//*[@id="associatedtype.Out0"]/*[@class="code-header"]' // @snapshot out9 - '//*[@id="associatedtype.Out9"]/*[@class="code-header"]' // // @has - '//*[@id="tymethod.make"]'  // "fn make<F>(F, impl FnMut(&str) -> bool) // where  //     F: FnOnce(u32) -> String,  //     Self::Out2<()>: Protocol<u8, Q0 = Self::Item, Q1 = ()>" pub use aux::Main; </ins>

Discussion:
<!-- Thank you for finding a documentation problem! Documentation problems might be grammatical issues, typos, or unclear wording, please provide details regarding the documentation including where it is present. Note: If your issue is for one of these, please use their dedicated issue tracker instead: The Rust Book: Rust by Example: The Edition Guide: The Cargo Book: The Clippy Book: The Reference: The Rustonomicon: The Embedded Book: All other documentation issues should be filed here. Or, if you find an issue related to rustdoc (e.g. doctest, rustdoc UI), please use the bug report or blank issue template instead. -- The definition of the trait looks like: Rustdoc renders this as: This makes the trait bound for the associated type verbose and cryptic. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label -A-docs C-bug T-rustdoc A-rustdoc-ui A-associated-items
I did a quick investigation: This reproduces on stable and nightly but only if the corresponding trait comes from an extern crate (which is the case with & ). Thus marking this issue as label A-cross-crate-reexports Minimal reproducer: claim
Highly related to / “duplicate” of although the latter is quite outdated.

Currently on nightly the declaration for looks like: ! While the actual declaration with attributes stripped is: Previously up till 1.48.0 this rendered as: ! Which is not great, but at least it has the information there. I tried to identify the PR which changed this in 1.49.0, but skimming the list from a few search queries none of them stood out to me. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Rendering the declaration without the attributes and outside core/std works just fine: !
Ooooh, it works on that it has this issue. Similarly on 1.48.0 showed the associated type bound nicely, only showed it as a clause.
I may have found the reason why we are skipping the associated type binding. So when an external item (in our case an associated type) gets documented it goes through which then goes through this visitor: Further down we get to: which produces (for the associated item): Then produces: <details<summaryOutput</summary</detailsThe last boils down to which gets discarded further down here (in a operation): Afaics, the reason the unexported trait gets properly "documented" is because a different code path is run which doesn't involve clean on a .
label A-cross-crate-reexports A-associated-items Update: The output is still incorrect but it now looks like this: claim

The documentation for is inconsistent in how it shows the constraints. The actual trait declaration looks like this: The matches this declaration as of 1.49.0-nightly ( 2020-10-08). This is good. However, the shows no constraints at all: The is even weirder, using an equality constraint that's not supported (), and this goes all the way back to . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is the relevant code for traits: This is the relevant code for trait bounds: After that it goes into and I'm not sure where it goes.
Well. I think I found the issue.
Hmm, changing that didn't help - it's always , at least when documenting .
The bounds passed to  are incorrect across crates. Here they are for the original crate: and for the re-export: In particular note that is completely empty.
This looks like the culprit: is the bindings.
This needs larger refactors to rustdoc than I'm comfortable making. is , but the only way to construct those is through which works on the hir, not s, and the HIR is not preserved across crates. Maybe is interested in refactoring this? ;)
Update: The current nightly output is still incorrect: I am already working on a fix and I have already assigned myself to the duplicates of this issue ( and ). claim
Awesome, thanks!