Skip to content
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

rustdoc: ?Sized bounds are missing for re-exports #20924

Closed
tomjakubowski opened this issue Jan 11, 2015 · 3 comments
Closed

rustdoc: ?Sized bounds are missing for re-exports #20924

tomjakubowski opened this issue Jan 11, 2015 · 3 comments
Labels
T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@tomjakubowski
Copy link
Contributor

For example:

// foo.rs
pub fn f<T: ?Sized>(_: &T) { }
// bar.rs
extern crate foo;

pub use foo::f;

The docs for bar::f will be missing the ?Sized bound on T.

@tomjakubowski
Copy link
Contributor Author

I have a fix for this but as usual, it created a whole host of new issues like : Sized appearing on every type parameter and the appearance of repeated bounds between the type parameter list and where clause which I'll fix up.

@kmcallister kmcallister added the T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. label Jan 11, 2015
@kmcallister
Copy link
Contributor

We have a lot of problems with things not propagating to re-exports. Perhaps we're handling re-exports in the wrong place?

@tomjakubowski
Copy link
Contributor Author

rustdoc's normal operation is, broadly:

  1. Run syntax checking, type checking, analysis, etc. on a crate.
  2. Walk the crate's AST, cleaning it up as it goes into a form more palatable for rendering and caching information like trait impls.
  3. Render the cleaned crate as HTML.

When it hits re-exported items though, it can't get ASTs for them, so it has to not only "inline" the document attribute for that item from the external crate but also clean an entirely different set of types (generally living in rustc::middle::ty), often undoing a lot of work done by the compiler to make something at least close to the original signature for the item.

I think the right, but maybe painful, thing to do would be to always build rustdocs from the compiled crate, and not from the AST, which would mean if a rustdoc feature is broken for re-exports it's also broken for "normal" items. It would also mean not re-implementing every feature twice, once for the AST and another for ty types.

@bors bors closed this as completed in 8a69d35 Jan 14, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

2 participants