Avoid leaking the query-job collection warning into the panic query stack#157351
Open
xmakro wants to merge 2 commits into
Open
Avoid leaking the query-job collection warning into the panic query stack#157351xmakro wants to merge 2 commits into
xmakro wants to merge 2 commits into
Conversation
`collect_active_query_jobs` with `CollectActiveJobsKind::PartialAllowed` is only used to print the query stack when the compiler panics. It intentionally skips any query state shard whose lock it cannot take without waiting, since a complete job map is not needed for that. Under the parallel front-end another thread can still hold a shard lock while the panic is being reported, so the skip happens nondeterministically and the `warn!` was printed into the panic output. Because warnings are shown by default, this leaked a "Failed to collect active jobs" line into the diagnostics of panicking compilations and made their output unstable. Lower the message to `debug!` so it stays available with `RUSTC_LOG` but no longer pollutes the default output.
rustbot
added
A-query-system
rustbot
added
the
S-waiting-on-review
rustbot
removed
the
S-waiting-on-author
Collaborator
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @JohnTitor (or someone else) some time within the next two weeks. Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (
Why was this reviewer chosen?The reviewer was selected based on:
|
…nt-end This test was marked ignore-parallel-frontend because the panic-time query stack collection could nondeterministically print a "Failed to collect active jobs" warning. With that warning lowered to debug! the ICE output is stable across runs, so replace the directive with a blank line rather than deleting it. The expected stderr is unchanged because the line numbers stay the same.
xmakro
force-pushed
the
fix/parallel-collect-jobs-warn
branch
from
f2efaa9 to
b6a2d84
Compare
Contributor
|
@bors r+ rollup |
Contributor
rust-bors
Bot
added
S-waiting-on-bors
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Jun 3, 2026
…arn, r=petrochenkov Avoid leaking the query-job collection warning into the panic query stack Part of rust-lang#154314. When the compiler panics it prints the active query stack. That collection runs with `CollectActiveJobsKind::PartialAllowed`, which deliberately skips any query state shard whose lock it cannot take without waiting, since a complete job map is not needed just to print a stack. Under the parallel front-end another thread can still hold a shard lock while the panic is being reported, so a shard is skipped nondeterministically and a `warn!("Failed to collect active jobs ...")` was printed. Because warnings are shown by default (the default `RUSTC_LOG` filter is `WARN`), this leaked an extra line into the diagnostics of panicking compilations and made their output differ run to run. The panicking thread's own query chain is always collectible (a query does not hold its shard lock while it runs), so the printed stack itself is unaffected; only the spurious warning varied. A skipped shard is expected and tolerated on this path, so `warn!` was the wrong level for it to begin with. This lowers the message to `debug!` so it stays available with `RUSTC_LOG` but no longer pollutes the default output, and re-enables the one ui test that was disabled because of it.
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
Jun 3, 2026
…arn, r=petrochenkov Avoid leaking the query-job collection warning into the panic query stack Part of rust-lang#154314. When the compiler panics it prints the active query stack. That collection runs with `CollectActiveJobsKind::PartialAllowed`, which deliberately skips any query state shard whose lock it cannot take without waiting, since a complete job map is not needed just to print a stack. Under the parallel front-end another thread can still hold a shard lock while the panic is being reported, so a shard is skipped nondeterministically and a `warn!("Failed to collect active jobs ...")` was printed. Because warnings are shown by default (the default `RUSTC_LOG` filter is `WARN`), this leaked an extra line into the diagnostics of panicking compilations and made their output differ run to run. The panicking thread's own query chain is always collectible (a query does not hold its shard lock while it runs), so the printed stack itself is unaffected; only the spurious warning varied. A skipped shard is expected and tolerated on this path, so `warn!` was the wrong level for it to begin with. This lowers the message to `debug!` so it stays available with `RUSTC_LOG` but no longer pollutes the default output, and re-enables the one ui test that was disabled because of it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of #154314.
When the compiler panics it prints the active query stack. That collection runs with
CollectActiveJobsKind::PartialAllowed, which deliberately skips any query state shard whose lock it cannot take without waiting, since a complete job map is not needed just to print a stack.Under the parallel front-end another thread can still hold a shard lock while the panic is being reported, so a shard is skipped nondeterministically and a
warn!("Failed to collect active jobs ...")was printed. Because warnings are shown by default (the defaultRUSTC_LOGfilter isWARN), this leaked an extra line into the diagnostics of panicking compilations and made their output differ run to run. The panicking thread's own query chain is always collectible (a query does not hold its shard lock while it runs), so the printed stack itself is unaffected; only the spurious warning varied.A skipped shard is expected and tolerated on this path, so
warn!was the wrong level for it to begin with. This lowers the message todebug!so it stays available withRUSTC_LOGbut no longer pollutes the default output, and re-enables the one ui test that was disabled because of it.