Change:
<ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // aux-build:issue-29584.rs // ignore-cross-compile extern crate issue_29584; // @has issue_29584/struct.Foo.html // @!has - 'impl Bar for' pub use issue_29584::Foo; </ins>

Discussion:
The link to "FullOps" on this page is broken:
Background for anyone who wants to tackle this: is an unstable trait defined in a module of (specifically in ). It is an implementation detail that should not leak out. Because of the above, the fix is to not list the trait on the implementing type's page, not to generate a doc page for . Other examples of such traits are and on and , which are also listed on the respective pages with dead links.
I want to give it a try, however i don't know what is the right way to test changes. How can i build only the related docs? Make docs rebuilds everything, so it takes a while (even with the flag). How can i quickly test the html output for the docs without rebuilding everything? I tried rustdoc 'path/to/file' too, but it is not able to compile the doc for that given file
Unfortunately, this kind of change is just going to take forever to test. :/ You have to point it at a crate root, not just any rust file.
:( I will give a try to rustdoc once more. Compilations on my machine take around 1 hour, so i don't know if i can fix something that way.
I believe I have an explanation. The annotation on the modules ensures no documentation is created for the module or any traits or similar contained within it. However, when assessing whether s should be hidden on other pages the documentation compiler considers only the hiddenness of the itself, not its containing module. I suspect the existing behaviour is working as intended—consider the case of someone putting their (given public types Foo and Bar) in a doc-hidden module and then wondering where the went. I recommend the simple fix of putting on the s of the public-not-public traits.
Thanka for tracking this down! You are right that impls in private modules should generally be displayed since they are public in a sense. But I think the current state of affairs is very unsatisfying, since Rustdoc generates broken docs for perfectly valid code. Shouldn't it at the very least somit links that will wind up dead? And if both trait and implementing type are dic(hidden), as is the case here, it seems like a reasonable heuristic to treat the impl as hidden too.

I'm less sure about hidden traits in public types (e.g., RawFloat and f64) but if it's overridable it also seems sensible.
Putting my real-world-concerns hat on, I think this is really just a corner case where and “public” don't coincide. The Right Thing is to propagate from traits to s of those traits; I don't know how difficult that is to do, so I opted for recommending a simple fix which I'd confirmed to work.