Rename the query system's JobOwner to ActiveJobGuard, and include key_hash#152377
Merged
rust-bors[bot] merged 2 commits intorust-lang:mainfrom Feb 9, 2026
Merged
Rename the query system's JobOwner to ActiveJobGuard, and include key_hash#152377rust-bors[bot] merged 2 commits intorust-lang:mainfrom
JobOwner to ActiveJobGuard, and include key_hash#152377rust-bors[bot] merged 2 commits intorust-lang:mainfrom
Conversation
rustbot
added
A-query-system
nnethercote
approved these changes
Feb 9, 2026
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
Feb 9, 2026
…ercote Rename the query system's `JobOwner` to `ActiveJobGuard`, and include `key_hash` `JobOwner` appears to have had more responsibilities in the past, but nowadays it's just a stack-guard object used by `execute_job` to poison the query state for the current key if some inner part of query execution panics. The new name and comments should hopefully be clearer about its (limited) role. I have also included a follow-up change that stores both the key and its previously-computed hash in the guard, instead of just the key. This avoids having to pass the key to `complete`, and avoids having to recompute the hash in `drop`. r? nnethercote (or compiler)
Contributor
|
⌛ Testing commit d2dbd38 with merge 0e3b79b... Workflow: https://github.com/rust-lang/rust/actions/runs/21819469043 |
rust-bors bot
pushed a commit
that referenced
this pull request
Feb 9, 2026
Rename the query system's `JobOwner` to `ActiveJobGuard`, and include `key_hash` `JobOwner` appears to have had more responsibilities in the past, but nowadays it's just a stack-guard object used by `execute_job` to poison the query state for the current key if some inner part of query execution panics. The new name and comments should hopefully be clearer about its (limited) role. I have also included a follow-up change that stores both the key and its previously-computed hash in the guard, instead of just the key. This avoids having to pass the key to `complete`, and avoids having to recompute the hash in `drop`. r? nnethercote (or compiler)
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Feb 9, 2026
…ercote Rename the query system's `JobOwner` to `ActiveJobGuard`, and include `key_hash` `JobOwner` appears to have had more responsibilities in the past, but nowadays it's just a stack-guard object used by `execute_job` to poison the query state for the current key if some inner part of query execution panics. The new name and comments should hopefully be clearer about its (limited) role. I have also included a follow-up change that stores both the key and its previously-computed hash in the guard, instead of just the key. This avoids having to pass the key to `complete`, and avoids having to recompute the hash in `drop`. r? nnethercote (or compiler)
Member
Author
rust-bors
bot
added
S-waiting-on-author
Contributor
|
Commit d2dbd38 has been unapproved. Auto build cancelled due to unapproval. Cancelled workflows: |
This commit also adds and updates some relevant comments.
This value is a previously-computed hash of the key, so it makes sense to bundle it with the key inside the guard, since the guard will need it on completion anyway.
Zalathar
force-pushed
the
active-job-guard
branch
from
d2dbd38 to
c475bda
Compare
Collaborator
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
Member
Author
|
Rebased over trivial conflict. @bors r=nnethercote |
Contributor
rust-bors
bot
added
S-waiting-on-bors
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Feb 9, 2026
…ercote Rename the query system's `JobOwner` to `ActiveJobGuard`, and include `key_hash` `JobOwner` appears to have had more responsibilities in the past, but nowadays it's just a stack-guard object used by `execute_job` to poison the query state for the current key if some inner part of query execution panics. The new name and comments should hopefully be clearer about its (limited) role. I have also included a follow-up change that stores both the key and its previously-computed hash in the guard, instead of just the key. This avoids having to pass the key to `complete`, and avoids having to recompute the hash in `drop`. r? nnethercote (or compiler)
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Feb 9, 2026
…ercote Rename the query system's `JobOwner` to `ActiveJobGuard`, and include `key_hash` `JobOwner` appears to have had more responsibilities in the past, but nowadays it's just a stack-guard object used by `execute_job` to poison the query state for the current key if some inner part of query execution panics. The new name and comments should hopefully be clearer about its (limited) role. I have also included a follow-up change that stores both the key and its previously-computed hash in the guard, instead of just the key. This avoids having to pass the key to `complete`, and avoids having to recompute the hash in `drop`. r? nnethercote (or compiler)
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Feb 9, 2026
…ercote Rename the query system's `JobOwner` to `ActiveJobGuard`, and include `key_hash` `JobOwner` appears to have had more responsibilities in the past, but nowadays it's just a stack-guard object used by `execute_job` to poison the query state for the current key if some inner part of query execution panics. The new name and comments should hopefully be clearer about its (limited) role. I have also included a follow-up change that stores both the key and its previously-computed hash in the guard, instead of just the key. This avoids having to pass the key to `complete`, and avoids having to recompute the hash in `drop`. r? nnethercote (or compiler)
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Feb 9, 2026
…ercote Rename the query system's `JobOwner` to `ActiveJobGuard`, and include `key_hash` `JobOwner` appears to have had more responsibilities in the past, but nowadays it's just a stack-guard object used by `execute_job` to poison the query state for the current key if some inner part of query execution panics. The new name and comments should hopefully be clearer about its (limited) role. I have also included a follow-up change that stores both the key and its previously-computed hash in the guard, instead of just the key. This avoids having to pass the key to `complete`, and avoids having to recompute the hash in `drop`. r? nnethercote (or compiler)
rust-bors bot
pushed a commit
that referenced
this pull request
Feb 9, 2026
Rollup of 12 pull requests Successful merges: - #152388 (`rust-analyzer` subtree update) - #151613 (Align `ArrayWindows` trait impls with `Windows`) - #152134 (Set crt_static_allow_dylibs to true for Emscripten target) - #152166 (cleanup some more things in `proc_macro::bridge`) - #152236 (compiletest: `-Zunstable-options` for json targets) - #152287 (Fix an ICE in the vtable iteration for a trait reference in const eval when a supertrait not implemented) - #142957 (std: introduce path normalize methods at top of `std::path`) - #145504 (Add some conversion trait impls) - #152131 (Port rustc_no_implicit_bounds attribute to parser.) - #152315 (fix: rhs_span to rhs_span_new) - #152327 (Check stalled coroutine obligations eagerly) - #152377 (Rename the query system's `JobOwner` to `ActiveJobGuard`, and include `key_hash`)
rust-bors bot
pushed a commit
that referenced
this pull request
Feb 9, 2026
Rollup of 12 pull requests Successful merges: - #152388 (`rust-analyzer` subtree update) - #151613 (Align `ArrayWindows` trait impls with `Windows`) - #152134 (Set crt_static_allow_dylibs to true for Emscripten target) - #152166 (cleanup some more things in `proc_macro::bridge`) - #152236 (compiletest: `-Zunstable-options` for json targets) - #152287 (Fix an ICE in the vtable iteration for a trait reference in const eval when a supertrait not implemented) - #142957 (std: introduce path normalize methods at top of `std::path`) - #145504 (Add some conversion trait impls) - #152131 (Port rustc_no_implicit_bounds attribute to parser.) - #152315 (fix: rhs_span to rhs_span_new) - #152327 (Check stalled coroutine obligations eagerly) - #152377 (Rename the query system's `JobOwner` to `ActiveJobGuard`, and include `key_hash`)
rust-bors bot
pushed a commit
that referenced
this pull request
Feb 9, 2026
Rollup of 12 pull requests Successful merges: - #152388 (`rust-analyzer` subtree update) - #151613 (Align `ArrayWindows` trait impls with `Windows`) - #152134 (Set crt_static_allow_dylibs to true for Emscripten target) - #152166 (cleanup some more things in `proc_macro::bridge`) - #152236 (compiletest: `-Zunstable-options` for json targets) - #152287 (Fix an ICE in the vtable iteration for a trait reference in const eval when a supertrait not implemented) - #142957 (std: introduce path normalize methods at top of `std::path`) - #145504 (Add some conversion trait impls) - #152131 (Port rustc_no_implicit_bounds attribute to parser.) - #152315 (fix: rhs_span to rhs_span_new) - #152327 (Check stalled coroutine obligations eagerly) - #152377 (Rename the query system's `JobOwner` to `ActiveJobGuard`, and include `key_hash`)
rust-timer
added a commit
that referenced
this pull request
Feb 9, 2026
Rollup merge of #152377 - Zalathar:active-job-guard, r=nnethercote Rename the query system's `JobOwner` to `ActiveJobGuard`, and include `key_hash` `JobOwner` appears to have had more responsibilities in the past, but nowadays it's just a stack-guard object used by `execute_job` to poison the query state for the current key if some inner part of query execution panics. The new name and comments should hopefully be clearer about its (limited) role. I have also included a follow-up change that stores both the key and its previously-computed hash in the guard, instead of just the key. This avoids having to pass the key to `complete`, and avoids having to recompute the hash in `drop`. r? nnethercote (or compiler)
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
3 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.
JobOwnerappears to have had more responsibilities in the past, but nowadays it's just a stack-guard object used byexecute_jobto poison the query state for the current key if some inner part of query execution panics.The new name and comments should hopefully be clearer about its (limited) role.
I have also included a follow-up change that stores both the key and its previously-computed hash in the guard, instead of just the key. This avoids having to pass the key to
complete, and avoids having to recompute the hash indrop.r? nnethercote (or compiler)