rustdoc links to the wrong method anchor

[jyn514]

I tried this code: https://github.com/laysakura/serde-encrypt/commit/b46c11860bf83845e6b8053d04525cb44295e510

I expected to see this happen: All links rustdoc generates are valid.

Instead, this happened: In impl<V: Multilane, T> VZip for T, on encrypt/encrypted_message/struct.EncryptedMessage.html, the function vzip links to #tymethod.vzip, but the proper link is #method.vzip. This causes the anchor to go nowhere.

Meta

rustdoc --version: rustdoc 1.53.0 (53cb7b09b 2021-06-17)

This is also present on rustdoc 1.55.0-nightly (7c3872e6b 2021-06-24).

[jyn514]

searched nightlies: from nightly-2021-04-14 to nightly-2021-04-16 regressed nightly: nightly-2021-04-15 searched commits: from https://github.com/rust-lang/rust/commit/132b4e5d167b7e622fcc11fa2b67b931105b4de1 to https://github.com/rust-lang/rust/commit/16bf626a31cb5b121d0bca2baa969b4f67eb0dab regressed commit: https://github.com/rust-lang/rust/commit/b203b0d240b67916cfa77f640aedaf1c87d50f6d

bisected with cargo-bisect-rustc v0.6.0

Host triple: x86_64-unknown-linux-gnu Reproduce with: ```bash cargo bisect-rustc --preserve --start 2021-04-14 --end 2021-04-16 -- deadlinks ```

cc @mockersf , do you have time to take a look?

[fee1-dead]

MCVE:

pub trait A {
    fn test();
}

pub struct Foo;

impl A for Foo {
    fn test() {}
}

playground

@rustbot label -E-needs-mcve

[fee1-dead]

Problem is: https://github.com/rust-lang/rust/blob/117799b73ccf434f588528d97596392062535e3f/src/librustdoc/html/render/mod.rs#L1353-L1359

Where the item from the trait is used to get source_id. This produces the error because it uses item.type_(), but the type is now TyMethod because it was in a trait. This can be just changed to item_type instead, which refers to the type of the impl method:

https://github.com/rust-lang/rust/blob/117799b73ccf434f588528d97596392062535e3f/src/librustdoc/html/render/mod.rs#L1286-L1295

To fix this, the suggestion above should be applied and the tests involving this need to be updated.

@rustbot label E-easy

[mockersf]

This seems to happen only for implementations of VZip: https://docs.rs/serde-encrypt-core/0.6.0/serde_encrypt_core/key/key_pair/public_key/struct.ReceiverPublicKey.html#impl-VZip%3CV%3E Not sure why, but the trait itself is not a link to the original trait.

It's https://docs.rs/ppv-lite86/0.2.10/ppv_lite86/trait.VZip.html#method.vzip, and on its own page the trait name is not a link in its implementations

The link correctly has a tymethod anchor, but it's missing the page to which it should link to find that anchor. I didn't manage yet to reproduce with a trait that would create the same situation as VZip does

[mockersf]

There are two links:

• the anchor on mouse over, which is a #method, and links to the current page
• the link on the function name, which is a #tymethod and should link to the trait definition page.

The issue is on the second one and it should stay a #tymethod I think

[fee1-dead]

This is more complicated than I think

@rustbot label E-needs-mcve -E-easy

[fee1-dead]

I actually can't reproduce this with the latest nightly with the crate. I cloned the repo, switched to that particular commit and ran cargo +nightly doc. The link is not broken.

[jyn514]

@fee1-dead try running deadlinks on it like in the original issue

[fee1-dead]

It reproduced after I ran cargo clean.

The significant difference might be that the first run did not have Checking ppv-lite86 v0.2.10

[mockersf]

I did not manage to isolate the issue, but I pushed a fix that works for serde-encrypt and that I understand

[jyn514]

Smaller reproduction (only 2 crates):

// lib.rs
use ppv_lite86::*;

pub struct S;

impl MultiLane<usize> for S {
    fn from_lanes(lanes: usize) -> Self {
        todo!();
    }
    fn to_lanes(self) -> usize {
        todo!()
    }
}

[jyn514]

MCVE (requires at least 2 crates):

// src/lib.rs
use ppv_lite86::*;

pub struct S;

// ppv_lite86/src/lib.rs
pub trait VZip {
    fn vzip() -> usize;
}

impl<T> VZip for T {
    fn vzip() -> usize {
        0
    }
}