-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revert "Cleanup markdown span handling" #80381
Conversation
Some changes occurred in intra-doc-links. cc @jyn514 |
Could you also add a UI test to prevent a future regression too please? |
This caused a diagnostic regression, originally it was: ``` warning: unresolved link to `std::process::Comman` --> link.rs:3:10 | 3 | //! [a]: std::process::Comman | ^^^^^^^^^^^^^^^^^^^^ no item named `Comman` in module `process` | = note: `#[warn(broken_intra_doc_links)]` on by default ``` but after that PR rustdoc now displays ``` warning: unresolved link to `std::process::Comman` --> link.rs:1:14 | 1 | //! Links to [a] [link][a] | ^^^ no item named `Comman` in module `process` | = note: `#[warn(broken_intra_doc_links)]` on by default ``` which IMO is much less clear.
0403b28
to
0f25712
Compare
@GuillaumeGomez done, good idea. |
Thanks! A bit sad for this change to be reverted but I guess it's going back to better jump. 😉 r=me once CI pass |
@bors r=GuillaumeGomez |
📌 Commit 0f25712 has been approved by |
…llaumeGomez Revert "Cleanup markdown span handling" Reverts rust-lang#80244. This caused a diagnostic regression, originally it was: ``` warning: unresolved link to `std::process::Comman` --> link.rs:3:10 | 3 | //! [a]: std::process::Comman | ^^^^^^^^^^^^^^^^^^^^ no item named `Comman` in module `process` | = note: `#[warn(broken_intra_doc_links)]` on by default ``` but after that PR rustdoc now displays ``` warning: unresolved link to `std::process::Comman` --> link.rs:1:14 | 1 | //! Links to [a] [link][a] | ^^^ no item named `Comman` in module `process` | = note: `#[warn(broken_intra_doc_links)]` on by default ``` which IMO is much less clear. cc `@bugadani,` thanks for catching this in rust-lang#77859. r? `@GuillaumeGomez`
Some notes:
|
Rollup of 7 pull requests Successful merges: - rust-lang#80185 (Fix ICE when pointing at multi bytes character) - rust-lang#80260 (slightly more typed interface to panic implementation) - rust-lang#80311 (Improvements to NatVis support) - rust-lang#80337 (Use `desc` as a doc-comment for queries if there are no doc comments) - rust-lang#80381 (Revert "Cleanup markdown span handling") - rust-lang#80492 (remove empty wraps, don't return Results from from infallible functions) - rust-lang#80509 (where possible, pass slices instead of &Vec or &String (clippy::ptr_arg)) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
This fixes a diagnostic regression that was introduced in 1.50, but the fix was only merged in 1.51. @rust-lang/rustdoc how do you feel about backporting this? The change is pretty small and only reverts an earlier change. |
I agree with the backport. |
Cleanup markdown span handling, take 2 This PR includes the cleanups made in rust-lang#80244 except for the removal of `locate()`. While the biggest conceptual part in rust-lang#80244 was the removal of `locate()`, it introduced a diagnostic regression. Additional cleanup: - Use `RefCell` to avoid building two separate vectors for the links Work to do: - [ ] Decide if `locate()` can be simplified by assuming `s` is always in `md` - [ ] Should probably add some tests that still provide the undesired diagnostics causing rust-lang#80381 cc `@jyn514` This is the best I can do without patching Pulldown to provide multiple ranges for reference-style links. Also, since `locate` is probably more efficient than `rfind` (at least it's constant time), I decided to not check the link type and just cover every &str as it was before.
beta backport discussed and approved during today's meeting |
Reverts #80244. This caused a diagnostic regression, originally it was:
but after that PR rustdoc now displays
which IMO is much less clear.
cc @bugadani, thanks for catching this in #77859.
r? @GuillaumeGomez