rustdoc: cannot resolve links to associated trait items for primitives

[classabbyamp]

I tried this code:

use std::{num::ParseFloatError, str::FromStr};

/// Uses the rules from [`f64::from_str()`].
pub struct Number {
    pub value: f64,
}

impl FromStr for Number {
    type Err = ParseFloatError;

    fn from_str(s: &str) -> Result<Self, Self::Err> {
        let value = s.parse::<f64>()?;
        Ok(Self{value})
    }
}

I expected to see this happen: the [f64::from_str()] in the docstring links to https://doc.rust-lang.org/1.56.0/std/primitive.f64.html#method.from_str

Instead, this happened:

cargo doc
 Documenting cayenne v0.1.0 (/home/abi/projects/classabbyamp/rspice)
warning: unresolved link to `f64::from_str`
 --> src/v.rs:3:27
  |
3 | /// Uses the rules from [`f64::from_str()`].
  |                           ^^^^^^^^^^^^^^^ the builtin type `f64` has no function named `from_str`
  |
  = note: `#[warn(rustdoc::broken_intra_doc_links)]` on by default

warning: `cayenne` (lib doc) generated 1 warning
    Finished dev [unoptimized + debuginfo] target(s) in 0.34s

This does not happen for [f64::floor()] nor for linking to a non-primitive FromStr implmentation, like [Number::from_str()] (in the example above).

@jyn514 suggested that resolve_primitive_associated_item() may be only looking at inherent impls and not trait impls, and that it may need a call to resolve_associated_trait_item().

Meta

rustc --version --verbose:

rustc 1.56.0 (09c42c458 2021-10-18)
binary: rustc
commit-hash: 09c42c45858d5f3aedfa670698275303a3d19afa
commit-date: 2021-10-18
host: x86_64-unknown-linux-gnu
release: 1.56.0
LLVM version: 13.0.0

Reproduced on beta:

rustc 1.57.0-beta.3 (708d57e28 2021-11-01)
binary: rustc
commit-hash: 708d57e288d051a6238ed56039ffeac158e10e84
commit-date: 2021-11-01
host: x86_64-unknown-linux-gnu
release: 1.57.0-beta.3
LLVM version: 13.0.0

and nightly:

rustc 1.58.0-nightly (46b8e7488 2021-11-07)
binary: rustc
commit-hash: 46b8e7488eae116722196e8390c1bd2ea2e396cf
commit-date: 2021-11-07
host: x86_64-unknown-linux-gnu
release: 1.58.0-nightly
LLVM version: 13.0.0

Backtrace

RUSTC_BOOTSTRAP=1 RUSTDOC_LOG=rustdoc::passes::collect_intra_doc_links=debug cargo rustdoc -- -Dwarnings -Ztreat-err-as-bug:

 Documenting cayenne v0.1.0 (/home/classabbyamp/projects/cayenne)
warning: some trace filter directives would enable traces that are disabled statically
 | `rustdoc::passes::collect_intra_doc_links=debug` would enable the DEBUG level for the `rustdoc::passes::collect_intra_doc_links` target
 = note: the static max level is `info`
 = help: to enable DEBUG logging, remove the `max_level_info` feature
DEBUG rustdoc::passes::collect_intra_doc_links::early doc=" Uses the rules from [`f64::from_str()`]."
DEBUG rustdoc::passes::collect_intra_doc_links::early link.link="`f64::from_str()`"
DEBUG rustdoc::passes::collect_intra_doc_links looking for the `Self` type
DEBUG rustdoc::passes::collect_intra_doc_links using item_name(): Some("cayenne")
DEBUG rustdoc::passes::collect_intra_doc_links looking for the `Self` type
DEBUG rustdoc::passes::collect_intra_doc_links using item_name(): Some("v")
DEBUG rustdoc::passes::collect_intra_doc_links looking for the `Self` type
DEBUG rustdoc::passes::collect_intra_doc_links using item_name(): Some("Number")
DEBUG rustdoc::passes::collect_intra_doc_links combined_docs=Uses the rules from [`f64::from_str()`].
DEBUG rustdoc::passes::collect_intra_doc_links f64::from_str resolved to Err(()) in namespace ValueNS
DEBUG rustdoc::passes::collect_intra_doc_links resolved primitives F64
DEBUG rustdoc::passes::collect_intra_doc_links looking for enum variant f64::from_str
DEBUG rustdoc::passes::collect_intra_doc_links f64::from_str resolved to Err(()) in namespace TypeNS
DEBUG rustdoc::passes::collect_intra_doc_links resolved primitives F64
DEBUG rustdoc::passes::collect_intra_doc_links resolving f64::from_str as a macro in the module DefId(0:3 ~ cayenne[f5be]::v)
DEBUG rustdoc::passes::collect_intra_doc_links f64 resolved to Ok(Primitive(F64)) in namespace TypeNS
DEBUG rustdoc::passes::collect_intra_doc_links found partial_res=Primitive(F64)
error: unresolved link to `f64::from_str`
 --> src/v.rs:3:27
  |
3 | /// Uses the rules from [`f64::from_str()`].
  |                           ^^^^^^^^^^^^^^^ the builtin type `f64` has no function named `from_str`
  |
  = note: `-D rustdoc::broken-intra-doc-links` implied by `-D warnings`

thread 'rustc' panicked at 'aborting due to `-Z treat-err-as-bug=1`', compiler/rustc_errors/src/lib.rs:1182:27
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

error: Unrecognized option: 'crate-version'

error: could not document `cayenne`

Caused by:
  process didn't exit successfully: `rustdoc --edition=2021 --crate-type lib --crate-name cayenne src/lib.rs -o /home/classabbyamp/projects/cayenne/target/doc --error-format=json --json=diagnostic-rendered-ansi -Dwarnings -Ztreat-err-as-bug -L dependency=/home/classabbyamp/projects/cayenne/target/debug/deps --crate-version 0.1.0` (exit status: 1)

[Mustafif]

Hello I tested your problem, and found that when I used [f64::from_str().unwrap()] I got no error.

use std::{num::ParseFloatError, str::FromStr};

/// Uses the rules from [`f64::from_str().unwrap()`].
#[derive(Debug)]
pub struct Number {
    pub value: f64,
}

impl FromStr for Number {
    type Err = ParseFloatError;

    fn from_str(s: &str) -> Result<Self, Self::Err> {
        let value = s.parse::<f64>()?;
        Ok(Self{value})
    }
}

When I run cargo doc:

cargo doc
 Documenting num_doc v0.1.0 (C:\Users\Musta\rust_tests\num_doc)
    Finished dev [unoptimized + debuginfo] target(s) in 0.75s

I also tested with a main.rs file, and I mean it does work:

mod num;
use num::Number;
use std::str::FromStr;
fn main(){
    let s = Number::from_str("6.7").unwrap();
    println!("{:?}", s);
}

I hope this helps, but I do find it weird cargo needed the unwrap to not give errors

[jyn514]

@Mustafif when you put a dot in a link, rustdoc treats it as a url, not an intra doc link

[Mustafif]

Oh my I did not realize that, thank you for informing me about that

[theryangeary]

I'd like to take a shot at this, if that's alright.

[jyn514]

@theryangeary go for it! :) if you need help, feel free to ask here or on Zulip.

[jyn514]

Just for posterity: the zulip thread for this is https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/help.20with.20.2390703.

[mdibaiee]

Hello, is this still being worked on? The last message on the Zulip thread is 25th November. If it's free to pick up I'd be happy to pick it up.

[theryangeary]

Feel free to take it over. I haven't had the time to work on it unfortunately.

…

On Thu, Dec 30, 2021, 06:38 Mahdi Dibaiee ***@***.***> wrote: Hello, is this still being worked on? The last message on the Zulip thread is 25th November. If it's free to pick up I'd be happy to pick it up. — Reply to this email directly, view it on GitHub <#90703 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABV7RLO7YCQWANQNTMNWIJLUTRADHANCNFSM5HTGWXYQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were assigned.Message ID: ***@***.***>

[mdibaiee]

@rustbot claim

[mdibaiee]

#92443 will fix this for "simple" primitives such as:
char, str, bool, never, usize, u{8, 16, 32, 64, 128}, isize, i{8, 16, 32, 64, 128} and f32, f64. However, for generic types that wrap around other types, such as Tuple, Array, Slice, RawPtr, etc. I was not able to make it work at first try. See the discussion here: #92443 (comment)

As such, I think this issue is now "partially" fixed, however more work is needed to make it work for these other types.

Should I create a separate issue for these unsupported ones, or should we just keep this same issue?

See the new issue: #92536