Change:
// reachable in rustdoc generated documentation if !did.is_local() { if let Some(traitref) = associated_trait { <del> if !cx.renderinfo.borrow().access_levels.is_public(traitref.def_id) { </del> <ins> let did = traitref.def_id; if !cx.renderinfo.borrow().access_levels.is_public(did) { </ins> return; } <del> } // Skip foreign unstable traits from lists of trait implementations and // such. This helps prevent dependencies of the standard library, for // example, from getting documented as "traits `u32` implements" which // isn't really too helpful. if let Some(trait_did) = associated_trait { if let Some(stab) = cx.tcx.lookup_stability(trait_did.def_id) { if stab.level.is_unstable() { </del> <ins> if let Some(stab) = tcx.lookup_stability(did) { if stab.level.is_unstable() && stab.feature == sym::rustc_private { </ins> return; } }

Discussion:
Missing Implementors for [][1] trait. Current output: ! While rustdoc displays [][2] trait implementors. Expected: Display Implementors for Join trait: : 1.47.0-nightly ( 2020-08-15) [1]: [2]: modify labels: T-rustdoc
This is a regression from stable-to-nightly: and beta one has Implementors section. cc
It has made it way to beta. Pattern trait is also affected: modify labels: I-prioritize
(Btw I think you can use as a shorthand)
The Borrow trait still has , I am not sure if this bug affect crates in ecosystem.
So I think this bug shouldn't affect stable traits, just most unstable traits I saw are affected.
There is high change that causing the regression, but I cannot prove that.
This is more likely to be than the refactor I think.
Yeah, I suspect that given it might make sense to revert anyway, since it doesn't actually accomplish the goal. Or someone more experienced with rustdoc may be able to suggest/implement a better patch.
New discovery: So far only trait exported to std affected. For example with Join trait, in alloc it is normal:
Oh right, I have MCVE, it needs two dummy crates. <details<summarydummy crate "unstabled"</summary</detailsCrate to run : modify labels: -E-needs-mcve
searched nightlies: from nightly-2020-06-04 to nightly-2020-07-17 regressed nightly: nightly-2020-07-17 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
That rollup includes both and ; of the two I think is the more likely culprit.
Marking as P-high .

appears on the current nightly's, even though it's not part of the (public) standard libraries. This appears to be , so maybe related to , cc Noticed by (assuming they use the same handle here and discord, if not, sorry :flushed:)
Relevant PRs (backtrace isn't really to blame here): ,
Maybe this should also skip the impl if there is no 'stability' attribute? ,
This is the default for everything not in the standard library. So it seems like the standard library needs special casing here. Maybe as simple as ?
Doesn't gimli get everything marked as unstable behind the rustc_private feature gate through a rustc flag?
MCVE: It doesn't require any external deps, just dummy crates included. The outermost crate is a fake std, realcore is fake core, gimli is fake gimli.