Skip to content

rustdoc: Fix redundant_explicit_links incorrectly firing (or not firing) under certain scenarios#155435

Open
tonywu6 wants to merge 1 commit intorust-lang:mainfrom
tonywu6:main
Open

rustdoc: Fix redundant_explicit_links incorrectly firing (or not firing) under certain scenarios#155435
tonywu6 wants to merge 1 commit intorust-lang:mainfrom
tonywu6:main

Conversation

@tonywu6
Copy link
Copy Markdown

@tonywu6 tonywu6 commented Apr 17, 2026

Hi! I found some issues with the rustdoc::redundant_explicit_links lint while working on a personal project.

  • After skipping a link that contains inline markups, the lint would incorrectly skip all the remaining links.

    For example, with the following snippet, the lint is fired for [Option][Option], but not [Result][Result]:

    //! [Option][Option]
    //! [**u8**][u8]     (skipped)
    //! [Result][Result]
    

    Happening because of a ? causing a loop to bail early:

    let display_link = link_data.resolvable_link.clone()?;

  • The lint is fired for links that specify titles (like [link](link "title")), except that wouldn't be applicable because it's not possible to specify a title without there also being an explicit target. For example:

    error: redundant explicit link target
    --> <anon>:5:12
      |
    5 | /// [drop](drop "This function is not magic")
      |      ----  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ explicit target is redundant
      |      |
      |      because label contains path that resolves to same destination
      |
      = note: when a link's destination is not specified,
              the label is used to resolve intra-doc links
    help: remove explicit link target
      |
    5 - /// [drop](drop "This function is not magic")
    5 + /// [drop]
      |
    

These are found as of:

rustdoc 1.97.0-nightly (1b8f2e46e 2026-04-17)
binary: rustdoc
commit-hash: 1b8f2e46e14b08208a53585570edd9206374aae8
commit-date: 2026-04-17
host: aarch64-apple-darwin
release: 1.97.0-nightly
LLVM version: 22.1.2

(Note: I ran ./x test tests/rustdoc-ui locally, but not ./x tidy due to my slow internet. There was an unrelated failed test at tests/rustdoc-ui/ice-bug-report-url.rs which I'm not sure about)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Apr 17, 2026
@rustbot
Copy link
Copy Markdown
Collaborator

rustbot commented Apr 17, 2026

r? @lolbinarycat

rustbot has assigned @lolbinarycat.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: rustdoc
  • rustdoc expanded to 9 candidates
  • Random selection from GuillaumeGomez, fmease, lolbinarycat, notriddle

@lolbinarycat
Copy link
Copy Markdown
Contributor

Thanks, and well done!

@bors r+ rollup

@rust-bors
Copy link
Copy Markdown
Contributor

rust-bors bot commented Apr 17, 2026

📌 Commit b967de6 has been approved by lolbinarycat

It is now in the queue for this repository.

@rust-bors rust-bors bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants