rustdoc cannot resolve specific trait impl functions

[mqudsi]

trait Foo {
   /// This function generally does foo without side effects. 
   /// See [`SpecialFoo::foo()`] for an example.
   fn foo();
}

struct SpecialFoo {}

impl Foo for SpecialFoo {
    /// This is a good example of doing [`Foo::foo()`]
    fn foo() {}
}

There's no way to have the link SpecialFoo:foo() resolve in the rustdoc, as SpecialFoo does not contain this function. Unless there's a special syntax for referring to SpecialFoo's Foo impl that would allow this.

[GuillaumeGomez]

There is always the absolute linking: [../struct.SpecialFoo.html/method.foo].

Otherwise you got a good point here.

Should this be fixed / working right now?

I'm running nightly rustc 1.45.0-nightly (664fcd3f0 2020-05-27), and the example from the OP still fails. Foo::foo can be resolved, but SpecialFoo::foo can't. Am I doing something wrong, or has this not yet been implemented or released?

$ cat src/lib.rs 
//! Check out the docs for [`SpecialFoo::foo`].

pub trait Foo {
   /// This function generally does foo without side effects.
   /// See [`SpecialFoo::foo`] for an example.
   fn foo();
}

pub struct SpecialFoo {}

impl Foo for SpecialFoo {
    /// This is a good example of doing [`Foo::foo`]
    fn foo() {}
}

$ cargo +nightly-2020-05-28 doc
 Documenting doctest v0.1.0 (/home/daboross/doctest)
warning: `[SpecialFoo::foo]` cannot be resolved, ignoring it.
 --> src/lib.rs:1:29
  |
1 | //! Check out the docs for [`SpecialFoo::foo`].
  |                             ^^^^^^^^^^^^^^^^^ cannot be resolved, ignoring
  |
  = note: `#[warn(intra_doc_link_resolution_failure)]` on by default
  = help: to escape `[` and `]` characters, just add '\' before them like `\[` or `\]`

warning: `[SpecialFoo::foo]` cannot be resolved, ignoring it.
 --> src/lib.rs:5:13
  |
5 |    /// See [`SpecialFoo::foo`] for an example.
  |             ^^^^^^^^^^^^^^^^^ cannot be resolved, ignoring
  |
  = help: to escape `[` and `]` characters, just add '\' before them like `\[` or `\]`

warning: 2 warnings emitted

    Finished dev [unoptimized + debuginfo] target(s) in 0.70s
$ cargo +nightly-2020-05-28 --version
cargo 1.45.0-nightly (9fcb8c1d2 2020-05-25)
$ rustc +nightly-2020-05-28 --version
rustc 1.45.0-nightly (664fcd3f0 2020-05-27)
$ rustdoc +nightly-2020-05-28 --version
rustdoc 1.45.0-nightly (664fcd3f0 2020-05-27)

Using foo() instead of foo in the links results in the same error.

[benesch]

I believe this issue was incorrectly closed. The linked PR makes these links work inside of the trait impl block itself. But this issue is also about making those links work from outside of the trait impl block.

@xliiv do you agree?

I believe this issue was incorrectly closed.

I'm leaning toward this opinion.

Confirmed, it's still unresolved.

So the issue here is we have SpecialFoo and there is no way (AFAIK) to query for its children (e.g. the foo method). Once we had the foo item we could search for a related trait or something (like it's done in #72173).
Of course, there is inherent_impls, but it only returns children of impl SomeItem case and here we have impl SomeTrait for SomeItem case instead.

For consideration:
https://rustc-dev-guide.rust-lang.org/query.html#adding-a-new-kind-of-query

[pitaj]

This still appears this is unresolved, unless some alternate syntax was added to resolve it since June.

It's a blocker for #78006, take a look at the Actions log for the errors

@jyn514

[jyn514]

The code in the original issue works without modification since #74489 (if you change it to have pub in front of the struct and trait); the generated link is

See <a href="../impl/struct.SpecialFoo.html#method.foo" title="SpecialFoo::foo()"><code>SpecialFoo::foo()</code></a> for an example.</p>

Your issue in #78006 is related to primitives, please open a separate issue for that.

[pitaj]

I'm sorry, but you're incorrect. If you'd looked at the actions log I linked, you'd see the following errors.

error: unresolved link to `self::net::TcpStream::read`
  --> library/std/src/io/buffered/bufreader.rs:24:26
   |
24 | /// [`TcpStream::read`]: crate::net::TcpStream::read
   |                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^ the struct `TcpStream` has no field or associated item named `read`
   |
   = note: `-D broken-intra-doc-links` implied by `-D warnings`

error: unresolved link to `self::net::TcpStream::write`
  --> library/std/src/io/buffered/bufwriter.rs:62:27
   |
62 | /// [`TcpStream::write`]: crate::net::TcpStream::write
   |                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the struct `TcpStream` has no field or associated item named `write`

error: unresolved link to `self::net::TcpStream::read`
  --> library/std/src/io/buffered/bufreader.rs:24:26
   |
24 | /// [`TcpStream::read`]: crate::net::TcpStream::read
   |                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^ the struct `TcpStream` has no field or associated item named `read`

Which to me seems to be related to this issue. There's more information on the PR comments here and here.

I was going to create a new issue about this, but I figured that this one was what I was looking for, since the PR you linked wasn't linked and the last comment is saying it isn't fixed yet. Perhaps there's a corner case or this is caused by missing pubs.

[mqudsi]

I don't see how this could be fixed, because at minimum you'd need a special syntax to resolve ambiguous matches. e.g. Foo implements traits Bar and Baz and both expose a method qux(). You'd need the docs intralink equivalent of <Foo as Bar>::qux, no?

[jyn514]

@mqudsi disambiguating a specific trait impl is #74563. But in the common case when Bar is the only trait implemented by Foo with an item named qux, it will work just fine.