Skip to content

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

Merged
merged 16 commits into from
May 25, 2014

Conversation

alexcrichton
Copy link
Member

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

@lilyball
Copy link
Contributor

Awesome! 👍

let cx = super::ctxtkey.get().unwrap();
let tcx = match cx.maybe_typed {
core::Typed(ref tcx) => tcx,
core::NotTyped(_) => fail!(),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unreachable!()? (Or something...)

@huonw
Copy link
Member

huonw commented May 24, 2014

I wonder if it's possible/worth it to move (most of) the external reading crate stuff to a submodule of clean, to avoid inflating that file by 20% (1700 -> 2100 lines).

Vec::new().move_iter()
}.peekable();
if names.peek().map(|s| s.as_slice()) == Some("self") {
let _ = names.next();
Copy link
Member

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.?

Copy link
Member Author

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.

@huonw
Copy link
Member

huonw commented May 24, 2014

A few doc string links could be updated to point to std (e.g. the ones in here).

Also, does this handle either form of iterated reexport?

  1. Reexporting a reexport directly:
    • A defines pub struct Foo;,
    • B has pub use A::Foo,
    • C has pub use B::Foo.
  2. Reexporting something containing a reexport:
    • A defines pub struct Foo;,
    • B has pub mod bar { pub use A::Foo; },
    • C has pub use B::bar;

I would imagine that these are both relatively rare (especially 1) and so are low-priority.

@huonw
Copy link
Member

huonw commented May 24, 2014

(Also, yay! ❤️)

@brson
Copy link
Contributor

brson commented May 24, 2014

Is thus behavior optional?

@alexcrichton
Copy link
Member Author

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 #[doc(no_inline)] (as the prelude uses).

@alexcrichton
Copy link
Member Author

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Old docs?

@huonw
Copy link
Member

huonw commented May 24, 2014

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.
@brson brson mentioned this pull request May 25, 2014
9 tasks
bors added a commit that referenced this pull request May 25, 2014
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
@bors bors closed this May 25, 2014
@bors bors merged commit 3100bc5 into rust-lang:master May 25, 2014
@alexcrichton alexcrichton deleted the more-rustdoc-inline branch May 28, 2014 02:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants