Intra-doc links do not resolve associated items for blanket impls

[jyn514]

I tried this code:

pub trait Trait {
    fn f();
}
impl<T> Trait for T {
    fn f() {}
}

pub mod inner {
    use crate::Trait;
    /// Link to [S::f]
    pub struct S;
}

I expected to see this happen: The link resolves to <S as Trait>::f

Instead, this happened: rustdoc can't resolve the link:

warning: unresolved link to `S::f`
  --> blanket.rs:10:18
   |
10 |     /// Link to [S::f]
   |                  ^^^^ the struct `S` has no field or associated item named `f`
   |
   = note: `#[warn(broken_intra_doc_links)]` on by default

Meta

rustdoc +nightly --version: rustdoc 1.49.0-nightly (ffa2e7ae8 2020-10-24)

cc @seeplusplus

After seeing #78761 I'm strongly considering getting rid of blanket impls altogether, clearly no one has been using them or they would have opened an issue. @Manishearth what do you think?

[jyn514]

Note that rustc resolves it fine if you call inner::S::f(); in a main function: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=973602a904ba477d3edd9ec90e6729a5

[jyn514]

Another related issue for after this is fixed: right now rustdoc doesn't consider scoping at all for blanket impls, only for direct impls like impl Trait for MyType. Notice how module isn't passed to get_blanket_impls:

rust/src/librustdoc/passes/collect_intra_doc_links.rs

Line 605 in b385598

let implicit_impls = crate::clean::get_auto_trait_and_blanket_impls(cx, ty, did);

[jyn514]

rustdoc doesn't consider scoping at all for blanket impls

If we change get_blanket_impls to take a filter parameter like I suggested in #78761 (comment), we could filter traits in scope there. The way to tell that is

        cx.enter_resolver(|resolver| {
            resolver.traits_in_scope(module).iter().find(|candidate| candidate.def_id == trait_).is_some()
        })

which is not as efficient as only looking up the relevant traits in the first place but I think is the best we can do while still being able to reuse the code for clean.

[seeplusplus]

Currently looking into fixing this,
@rustbot claim