Skip to content

Conversation

@matthiaskrgr
Copy link
Member

@matthiaskrgr matthiaskrgr commented Nov 30, 2025

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

Zalathar and others added 8 commits November 30, 2025 18:31
…ocess, r=lolbinarycat

Fix bad intra-doc-link preprocessing

How did rust-lang#147981 happen?

1. We don't parse intra-doc links as Rust paths or qpaths. Instead they follow a very lenient bespoke grammar. We completely ignore Markdown links if they contain characters that don't match `/[a-zA-Z0-9_:<>, !*&;]/` (we don't even emit lint *broken-intra-doc-links* for these).
2. PR [rust-lang#132748](rust-lang#132748) made rustdoc intepret more Markdown links as potential intra-doc links. Namely, if the link is surrounded by backticks (and some other conditions apply) then it doesn't matter if the (partially processed) link contains bad characters as defined above (cc `ignore_urllike && should_ignore_link(path_str)`).
3. However, rustdoc's `preprocess_link` must be kept in sync with a simplified counterpart in rustc. More specifically, whenever rustdoc's preprocessor returns a successful result then rustc's must yield the same result. Otherwise, rustc doesn't resolve the necessary links for rustdoc.
4. This uncovered a "dormant bug" / "mistake" in rustc's `preprocess_link`. Namely, when presented with a link like `struct@Type@suffix`, it didn't cut off the disambiguator if present (here: `struct@`). Instead it `rsplit('`@')`` which is incorrect if the "path" contains ``@`` itself (yielding `suffix` instead of `Type@suffix` here). Prior to PR [rust-lang#132748](rust-lang#132748), a link like ``[`struct@Type@suffix`]`` was not considered a potential intra-doc link / worth querying rustc for. Now it is due to the backticks.
5. Finally, since rustc didn't record a resolution for `Type@suffix` (it only recorded `suffix` (to be `Res::Err`)), we triggered an assertion we have in place to catch cases like this.

Fixes rust-lang#147981.

I didn't and still don't have the time to investigate if rust-lang#132748 led to more rustc/rustdoc mismatches (after all, the PR made rustdoc's `preprocess_link` return `Some(Ok(_))` in more cases). I've at least added another much needed "warning banner" & made the existing one more flashy.

While this fixes a stable-to-beta regression, I don't think it's worth beta backporting, esp. since it's only P-medium and since the final 1.91 release steps commence today / the next days, so it would only be stressful to get it in on time. However, feel free to nominate.

<sub>(I've written such a verbose PR description since I tend to reread my old PR descriptions in the far future to fully freshen my memories when I have to work again in this area)</sub>

r? `@lolbinarycat`
coverage: Store signature/body spans and branch spans in the expansion tree

In order to support coverage instrumentation of expansion regions, we need to reduce the amount of code that assumes we're only instrumenting a flat function body. Moving more data into expansion tree nodes is an incremental step in that direction.

There should be no change to compiler output.
ThreadId generation fallback path: avoid spurious yields

Fixes rust-lang/miri#4737
Alternative to rust-lang#149476
Cc `@orlp` `@joboet`
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Nov 30, 2025
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Collaborator

bors commented Nov 30, 2025

📌 Commit c0320dc has been approved by matthiaskrgr

It is now in the queue for this repository.

@bors bors 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 Nov 30, 2025
bors added a commit that referenced this pull request Nov 30, 2025
Rollup of 3 pull requests

Successful merges:

 - #148169 (Fix bad intra-doc-link preprocessing)
 - #149471 (coverage: Store signature/body spans and branch spans in the expansion tree)
 - #149481 (ThreadId generation fallback path: avoid spurious yields)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors
Copy link
Collaborator

bors commented Nov 30, 2025

⌛ Testing commit c0320dc with merge a173b9b...

@rust-log-analyzer
Copy link
Collaborator

The job dist-powerpc-linux failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)
[RUSTC-TIMING] object test:false 5.021
error[E0061]: this method takes 2 arguments but 3 arguments were supplied
   --> library/std/src/thread/id.rs:75:38
    |
 75 |                 while COUNTER_LOCKED.swap(true, Ordering::Acquire, Ordering::Relaxed) {
    |                                      ^^^^                          ----------------- unexpected argument #3 of type `core::sync::atomic::Ordering`
    |
note: method defined here
   --> /rustc/a173b9b7f73f5db079e1d2feedc7067d6e2444ef/library/core/src/sync/atomic.rs:786:12
    |
786 |     pub fn swap(&self, val: bool, order: Ordering) -> bool {
    |            ^^^^
help: remove the extra argument
    |
 75 -                 while COUNTER_LOCKED.swap(true, Ordering::Acquire, Ordering::Relaxed) {
 75 +                 while COUNTER_LOCKED.swap(true, Ordering::Acquire) {
    |

For more information about this error, try `rustc --explain E0061`.
[RUSTC-TIMING] std test:false 3.533
error: could not compile `std` (lib) due to 1 previous error

@bors
Copy link
Collaborator

bors commented Nov 30, 2025

💔 Test failed - checks-actions

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

Labels

rollup A PR which is a rollup T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. 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.

7 participants