rustdoc links to the wrong method anchor

[jyn514]

I tried this code: laysakura/serde-encrypt@b46c118

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 (53cb7b0 2021-06-17)

This is also present on rustdoc 1.55.0-nightly (7c3872e 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 132b4e5 to 16bf626
regressed commit: b203b0d

bisected with cargo-bisect-rustc v0.6.0

Host triple: x86_64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc --preserve --start 2021-04-14 --end 2021-04-16 -- deadlinks 

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

[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
    }
}