-
Notifications
You must be signed in to change notification settings - Fork 13.4k
rustdoc: Inline documentation across crates #14391
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
Conversation
Awesome! 👍 |
let cx = super::ctxtkey.get().unwrap(); | ||
let tcx = match cx.maybe_typed { | ||
core::Typed(ref tcx) => tcx, | ||
core::NotTyped(_) => fail!(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unreachable!()
? (Or something...)
I wonder if it's possible/worth it to move (most of) the external reading crate stuff to a submodule of |
Vec::new().move_iter() | ||
}.peekable(); | ||
if names.peek().map(|s| s.as_slice()) == Some("self") { | ||
let _ = names.next(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is skipping the self
arg right? How will this interact with generalised self
? I.e. will we want to be recording self: Rc<Self>
vs. self: Box<Self>
etc.?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that once the compiler officially supports self
arguments the rustdoc changes may just fall out. I would imagine that the support for explicit selfs in rustdoc would change to accomodate a use case such as that.
A few doc string links could be updated to point to Also, does this handle either form of iterated reexport?
I would imagine that these are both relatively rare (especially 1) and so are low-priority. |
(Also, yay! ❤️) |
Is thus behavior optional? |
That's a good point that this doesn't handle recursive inlining of reexports, I'll leave it as a FIXME for now. You can disable this behavior with |
Updated with all comments address (I think at least!) |
// option. This file may not be copied, modified, or distributed | ||
// except according to those terms. | ||
|
||
//! This module contains the "cleaned" pieces of the AST, and the functions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Old docs?
r=me with minor comments, and the travis failure seems to be relevant. |
This commit teaches rustdoc to inline the documentation for the destination of a `pub use` statement across crate boundaries. This is intended for the standard library's facade to show the fact that the facade is just an implementation detail rather than the api of the standard library itself. This starts out by inlining traits and functions, but more items will come soon. The current drawback of this system is that hyperlinks across crates sill go to the original item's definition rather than the reexported location.
For now just assume that the enum type itself is reexported.
The normal analysis passes aren't guaranteed to have loaded all impls, so use the csearch methods directly to load impls.
This will allow for rustdoc to pick up the documentation on the other end.
The field passed from markdown could sometimes be null, and it wasn't properly handled.
Within the documentation for a crate, all hyperlinks to reexported items don't go across crates, but rather to the items in the crate itself. This will allow references to Option in the standard library to link to the standard library's Option, instead of libcore's. This does mean that other crate's links for Option will still link to libcore's Option.
These links work by hyperlinking back to the actual documentation page with a query parameter which will be recognized and then auto-click the appropriate [src] link.
As part of the libstd facade (cc #13851), rustdoc is taught to inline documentation across crate boundaries through the usage of a `pub use` statement. This is done to allow libstd to maintain the facade that it is a standalone library with a defined public interface (allowing us to shuffle around what's underneath it). A preview is available at http://people.mozilla.org/~acrichton/doc/std/index.html
As part of the libstd facade (cc #13851), rustdoc is taught to inline documentation across crate boundaries through the usage of a
pub use
statement. This is done to allow libstd to maintain the facade that it is a standalone library with a defined public interface (allowing us to shuffle around what's underneath it).A preview is available at http://people.mozilla.org/~acrichton/doc/std/index.html