-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Remove CrateNum parameter for queries that only work on local crate #85178
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
Conversation
r? @varkor (rust-highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 744dece9b42ec88e849099716a81b1a99bcfaab1 with merge f690672c840f1ece42fcb14f6143579ce2f69016... |
☀️ Try build successful - checks-actions |
Queued f690672c840f1ece42fcb14f6143579ce2f69016 with parent 506e75c, future comparison URL. |
I have tried something similar in #71648 but I gave up^^ |
Finished benchmarking try commit (f690672c840f1ece42fcb14f6143579ce2f69016): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
Sorry for the noise here but is this idea abandoned/discussed recently somewhere? |
☔ The latest upstream changes (presumably #83610) made this pull request unmergeable. Please resolve the merge conflicts. |
pub(super) fn index_hir<'tcx>(tcx: TyCtxt<'tcx>, cnum: CrateNum) -> &'tcx IndexedHir<'tcx> { | ||
assert_eq!(cnum, LOCAL_CRATE); | ||
|
||
pub(super) fn index_hir<'tcx>(tcx: TyCtxt<'tcx>, (): ()) -> &'tcx IndexedHir<'tcx> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have to have a (): ()
parameter? Presumably this is a quirk of the query system?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The query system is designed to work with queries taking exactly two arguments: the TyCtxt and a key. I am not convinced that removing the extra ()
parameter is worth the added complexity in the query system. (I am not even sure this is possible without a sizeable modification to the query plumbing.)
I think it'd be better for someone more familiar with the query system to review here. r? @oli-obk |
niko mentioned this in #71648 (comment) considering the approval of niko and eddyb in #71648 let's go ahead with this idea the changes themselves lgtm @bors r+ rollup=never (bitrotty I presume) |
📌 Commit 1ebf6d1 has been approved by |
☀️ Test successful - checks-actions |
Tested on commit rust-lang/rust@3396a38. Direct link to PR: <rust-lang/rust#85178> 💔 miri on windows: test-pass → build-fail (cc @oli-obk @RalfJung @eddyb). 💔 miri on linux: test-pass → build-fail (cc @oli-obk @RalfJung @eddyb).
Remove CrateNum parameter for queries that only work on local crate The pervasive `CrateNum` parameter is a remnant of the multi-crate rustc idea. Using `()` as query key in those cases avoids having to worry about the validity of the query key.
Remove CrateNum parameter for queries that only work on local crate The pervasive `CrateNum` parameter is a remnant of the multi-crate rustc idea. Using `()` as query key in those cases avoids having to worry about the validity of the query key.
The pervasive
CrateNum
parameter is a remnant of the multi-crate rustc idea.Using
()
as query key in those cases avoids having to worry about the validity of the query key.