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 has broken links for enum imports #29814

Closed
Manishearth opened this issue Nov 13, 2015 · 4 comments
Closed

Rustdoc has broken links for enum imports #29814

Manishearth opened this issue Nov 13, 2015 · 4 comments
Labels
C-bug Category: This is a bug. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@Manishearth
Copy link
Member

http://manishearth.github.io/rust-internals-docs/rustc/middle/ty/

If you click on the BuiltinBound in pub use self::sty::BuiltinBound::Send as BoundSend;, you're taken to http://manishearth.github.io/rust-internals-docs/rustc/middle/ty/sty/BuiltinBound/index.html instead of http://manishearth.github.io/rust-internals-docs/rustc/middle/ty/enum.BuiltinBound.html.

Also the sty link is broken, probably due to privacy.

@Manishearth Manishearth added the T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. label Nov 13, 2015
@mitaa
Copy link
Contributor

mitaa commented Dec 21, 2015

The problem is that the code formatting the path assumes that all path-segments except the last one are modules, emitting BuiltinBound/index.html instead of enum.BuiltinBound.html
https:/rust-lang/rust/blob/master/src/librustdoc/html/format.rs#L347

@mitaa
Copy link
Contributor

mitaa commented Feb 13, 2016

The deeper problem is that rustc (hir::{Path, PathSegment, ..}) doesn't give enough information (just an ident) about the path-segments to rustdoc so that we can ascertain the item-type necessary for creating the hyperlink.

I'm not sure how this ought to be solved:

  • Somehow attaching resolved DefId's within rustc to the path-segments? (metadata bloat?)
  • Running resolve within rustdoc and resolving each path-segment? (I've experimented with this some time ago and it seemed to be a viable solution, though a bit odd)
  • Simply omit these possibly broken links

cc @alexcrichton

@alexcrichton
Copy link
Member

In theory when rustdoc runs we have the entire results of resolve, right? Along those lines I figured the resolution would be somewhere...

@steveklabnik steveklabnik added T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. and removed T-tools labels May 18, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-bug Category: This is a bug. label Jul 24, 2017
@Mark-Simulacrum
Copy link
Member

I don't think I can reproduce this today, but since there's not really a minimal example here it's hard to tell. The code below generates a valid link for A in foo::bar::A but no more than that, which seems to be enough to resolve this issue.

pub mod foo {
    pub enum Bar {
        A,
        B,
        C,
    }
}

pub use foo::Bar::A as Apple;

pub fn main() {}

bors added a commit that referenced this issue Dec 29, 2017
rustdoc: Don't try to generate links for modules in import paths

The modules may be private or may even be enums so it would generate dead links.

Fixes #29814
Fixes #46766
Fixes #46767
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. 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

5 participants