Rustdoc has broken links for enum imports

[Manishearth]

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.

[mitaa]

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://github.com/rust-lang/rust/blob/master/src/librustdoc/html/format.rs#L347

[mitaa]

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]

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

[Mark-Simulacrum]

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() {}