Uh oh!
There was an error while loading. Please reload this page.
rustdoc: Fix LinkReplacer link matching - #108459
Conversation
rustbot
commented
Feb 25, 2023
r? @jsha (rustbot has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
benediktwerner
commented
Feb 26, 2023
Hm, the failing test confused me a bit but I guess it's just wrong or written with this bug in mind? Swapping the two I guess I'll also add a new test to explicitly check for the stuff this PR fixes. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
GuillaumeGomez
commented
Mar 25, 2023
Sorry for taking so long to review this fix. Don't hesitate to reroll it or ping someone else from the rustdoc team directly. Anyway, just questions and then let's approve it. Thanks for working on this! |
GuillaumeGomez
commented
Mar 26, 2023
Thanks! @bors r+ rollup |
bors
commented
Mar 26, 2023
bors
commented
Mar 26, 2023
🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened. |
…tch, r=GuillaumeGomez rustdoc: Fix LinkReplacer link matching It currently just uses the first link with the same href which might not necessarily be the matching one. This fixes replacements when there are several links to the same item but with different text (e.g. `[X] and [struct@X]`). It also fixes replacements in summaries since those use a links list with empty hrefs, so currently all links would always match the first link by href but then not match its text. This could also lead to a panic in the `original_lext[1..len() - 1]` part when the first link only has a single character, which is why the new code uses `.get(..)` instead.
GuillaumeGomez
commented
Mar 27, 2023
@bors r+ rollup |
bors
commented
Mar 27, 2023
📌 Commit c92d3adc108ba5979b4f9cb5b469a6e5adaa8518 has been approved by It is now in the queue for this repository. |
This comment has been minimized.
This comment has been minimized.
GuillaumeGomez
commented
Mar 27, 2023
While we're at it, please squash your commits. @bors r- |
JohnCSimon
commented
May 28, 2023
ping from triage - can you post your status on this PR? There hasn't been an update in a few months. Thanks! FYI: when a PR is ready for review, send a message containing |
c92d3ad to
9968f3cComparebenediktwerner
commented
May 30, 2023
Ah, sorry, looks like I missed the changes here. Fixed the formatting and squashed the commits. @rustbot ready |
GuillaumeGomez
commented
May 31, 2023
Thanks! @bors r+ rollup |
bors
commented
May 31, 2023
Rollup of 7 pull requests Successful merges: - rust-lang#108459 (rustdoc: Fix LinkReplacer link matching) - rust-lang#111318 (Add a distinct `OperandValue::ZeroSized` variant for ZSTs) - rust-lang#111892 (rustdoc: add interaction delays for tooltip popovers) - rust-lang#111980 (Preserve substs in opaques recorded in typeck results) - rust-lang#112024 (Don't suggest break through nested items) - rust-lang#112128 (Don't compute inlining status of mono items in advance.) - rust-lang#112141 (remove reference to Into in ? operator core/std docs, fixrust-lang#111655) Failed merges: - rust-lang#112071 (Group rfcs tests) r? `@ghost` `@rustbot` modify labels: rollup
It currently just uses the first link with the same href which might not necessarily be the matching one.
This fixes replacements when there are several links to the same item but with different text (e.g.
[X] and [struct@X]). It also fixes replacements in summaries since those use a links list with empty hrefs, so currently all links would always match the first link by href but then not match its text. This could also lead to a panic in theoriginal_lext[1..len() - 1]part when the first link only has a single character, which is why the new code uses.get(..)instead.