Rejig `rustc_with_all_queries!` by nnethercote · Pull Request #153161 · rust-lang/rust

nnethercote · 2026-02-27T02:34:50Z

View all comments

There are three things relating to rustc_with_all_queries! that have been bugging me.

rustc_with_all_queries!'s ability to receive extra_fake_queries lines like [] fn Null(()) -> (), where the only real thing is the Null, and everything is just pretending to be a normal query, ugh.
make_dep_kind_array!: a macro produced by one macro (define_dep_nodes!) and used by another macro (define_queries!) in another crate, ugh.
The _dep_kind_vtable_ctors module, which is a special module with no actual code that serves just a way of collecting vtable constructors from two different places so they can be referred to by make_dep_kind_array!, ugh.

By making some adjustments to how rustc_with_all_queries! works, all three of these things are eliminated.

r? @Zalathar

rustbot · 2026-02-27T02:34:54Z

Zalathar is not on the review rotation at the moment.
They may take a while to respond.

nnethercote · 2026-02-27T02:36:49Z

@Zalathar: I find it hard to predict where our opinions will align on cleanups, but I figure I'll just keep throwing stuff against the wall to see what sticks.

A couple of things I'm uncertain about this one:

I've used the term "non-queries" for Null, Red, etc. Not sure that's the best. "Fake" queries, maybe?
As per the "njn:" comment, I'm not sure if the proc macro is the best place to embed the list of non-queries.

I'm interested to hear what you think, thanks.

compiler/rustc_macros/src/query.rs

compiler/rustc_query_impl/src/dep_kind_vtables.rs

Zalathar · 2026-02-27T05:06:26Z

At first this didn't jump out to me as a big improvement, but after pondering it some more I think it's probably a good direction.

The part I really like is being able to get rid of $extra_fake_queries from rustc_with_all_queries!.

Having to explicitly ignore non_queries in all of the other callback macros is a bit unfortunate, but I think it's a good tradeoff, because it's just a tiny bit of boilerplate that is easily ignored.

I don't have great suggestions for what to call the non-query dep kinds. Some possibilities that come to mind are non_query_dep_kinds or special_dep_kinds, which are perhaps a little bit more self-describing when seen in contexts that don't care about things that aren't queries.

rustbot · 2026-03-01T22:06:59Z

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.

nnethercote · 2026-03-01T22:07:29Z

Comments addressed, should be ready for re-review.

compiler/rustc_macros/src/query.rs

compiler/rustc_middle/src/dep_graph/dep_node.rs

compiler/rustc_middle/src/queries.rs

compiler/rustc_query_impl/src/plumbing.rs

compiler/rustc_query_impl/src/dep_kind_vtables.rs

Zalathar · 2026-03-02T02:11:52Z

Thanks, r=me after resolving and/or rejecting each of the nits.

`rustc_with_all_queries` currently provides information about all queries. Also, a caller can provide an ad hoc list of extra non-queries. This is used by `define_queries` for non-query dep kinds: `Null`, `Red`, etc. This is pretty hacky. This commit changes `rustc_with_all_queries` so that the non-queries information is available to all callers. (Some callers ignore the non-query information.) This is done by adding `non_query` entries to the primary list of queries in `rustc_queries!`.

Currently `define_dep_nodes` produces a macro `make_dep_kind_array` that encodes the names of non-queries followed by queries. This macro is used by `make_dep_kind_vtables` to make the full array of vtables, by referring to vtable constructor functions that are put into `mod _dep_kind_vtable_ctors`. Pretty weird! This commit takes advantage of the previous commit's changes to `rustc_with_all_queries`, which makes both query and non-query information available. A new call to `rustc_with_all_queries` is used to construct the vtable array. (This moves some dep_kind_vtable code from `plumbing.rs` to `dep_kind_vtables.rs`, which is good.) It's straightforward now with iterator chaining, and `mod _dep_kind_vtable_ctors` is no longer needed.

nnethercote · 2026-03-02T05:20:58Z

I addressed all the nits. Let's do a perf run to be safe.

@bors try @rust-timer queue

…try> Rejig `rustc_with_all_queries!`

rust-timer · 2026-03-02T08:32:18Z

Finished benchmarking commit (dc13f8f): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary -0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.6%	[2.4%, 4.8%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-7.5%	[-7.5%, -7.5%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.1%	[-7.5%, 4.8%]	3

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 480.149s -> 477.903s (-0.47%)
Artifact size: 396.96 MiB -> 396.96 MiB (-0.00%)

nnethercote · 2026-03-02T08:51:36Z

No perf effects.

@bors r=Zalathar rollup=maybe

rust-bors · 2026-03-02T08:51:40Z

📌 Commit 40b2274 has been approved by Zalathar

It is now in the queue for this repository.

@Zalathar

…ueries, r=Zalathar Rejig `rustc_with_all_queries!` There are three things relating to `rustc_with_all_queries!` that have been bugging me. - `rustc_with_all_queries!`'s ability to receive `extra_fake_queries` lines like `[] fn Null(()) -> (),` where the only real thing is the `Null`, and everything is just pretending to be a normal query, ugh. - `make_dep_kind_array!`: a macro produced by one macro (`define_dep_nodes!`) and used by another macro (`define_queries!`) in another crate, ugh. - The `_dep_kind_vtable_ctors` module, which is a special module with no actual code that serves just a way of collecting vtable constructors from two different places so they can be referred to by `make_dep_kind_array!`, ugh. By making some adjustments to how `rustc_with_all_queries!` works, all three of these things are eliminated. r? @Zalathar

@Zalathar

…ueries, r=Zalathar Rejig `rustc_with_all_queries!` There are three things relating to `rustc_with_all_queries!` that have been bugging me. - `rustc_with_all_queries!`'s ability to receive `extra_fake_queries` lines like `[] fn Null(()) -> (),` where the only real thing is the `Null`, and everything is just pretending to be a normal query, ugh. - `make_dep_kind_array!`: a macro produced by one macro (`define_dep_nodes!`) and used by another macro (`define_queries!`) in another crate, ugh. - The `_dep_kind_vtable_ctors` module, which is a special module with no actual code that serves just a way of collecting vtable constructors from two different places so they can be referred to by `make_dep_kind_array!`, ugh. By making some adjustments to how `rustc_with_all_queries!` works, all three of these things are eliminated. r? @Zalathar

…uwer Rollup of 5 pull requests Successful merges: - #151962 (Fix next-solver ICE on PointeeSized goals) - #153161 (Rejig `rustc_with_all_queries!`) - #152164 (Lint unused features) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs)

@Zalathar

…ueries, r=Zalathar Rejig `rustc_with_all_queries!` There are three things relating to `rustc_with_all_queries!` that have been bugging me. - `rustc_with_all_queries!`'s ability to receive `extra_fake_queries` lines like `[] fn Null(()) -> (),` where the only real thing is the `Null`, and everything is just pretending to be a normal query, ugh. - `make_dep_kind_array!`: a macro produced by one macro (`define_dep_nodes!`) and used by another macro (`define_queries!`) in another crate, ugh. - The `_dep_kind_vtable_ctors` module, which is a special module with no actual code that serves just a way of collecting vtable constructors from two different places so they can be referred to by `make_dep_kind_array!`, ugh. By making some adjustments to how `rustc_with_all_queries!` works, all three of these things are eliminated. r? @Zalathar

…uwer Rollup of 9 pull requests Successful merges: - #153153 (add tests for thumb interworking) - #149328 (Add `String<A>` type with custom allocator parameter) - #151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - #151962 (Fix next-solver ICE on PointeeSized goals) - #153015 (core: make atomic primitives type aliases of `Atomic<T>`) - #153161 (Rejig `rustc_with_all_queries!`) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs) - #153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute)

@Zalathar

…ueries, r=Zalathar Rejig `rustc_with_all_queries!` There are three things relating to `rustc_with_all_queries!` that have been bugging me. - `rustc_with_all_queries!`'s ability to receive `extra_fake_queries` lines like `[] fn Null(()) -> (),` where the only real thing is the `Null`, and everything is just pretending to be a normal query, ugh. - `make_dep_kind_array!`: a macro produced by one macro (`define_dep_nodes!`) and used by another macro (`define_queries!`) in another crate, ugh. - The `_dep_kind_vtable_ctors` module, which is a special module with no actual code that serves just a way of collecting vtable constructors from two different places so they can be referred to by `make_dep_kind_array!`, ugh. By making some adjustments to how `rustc_with_all_queries!` works, all three of these things are eliminated. r? @Zalathar

…uwer Rollup of 11 pull requests Successful merges: - #153153 (add tests for thumb interworking) - #149328 (Add `String<A>` type with custom allocator parameter) - #151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - #151962 (Fix next-solver ICE on PointeeSized goals) - #153015 (core: make atomic primitives type aliases of `Atomic<T>`) - #153161 (Rejig `rustc_with_all_queries!`) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs) - #153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute) - #153293 (library: std: process: skip tests on Hermit) - #153301 (Do not ping kobzol on rustc-dev-guide changes)

…uwer Rollup of 10 pull requests Successful merges: - #153153 (add tests for thumb interworking) - #151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - #151962 (Fix next-solver ICE on PointeeSized goals) - #153015 (core: make atomic primitives type aliases of `Atomic<T>`) - #153161 (Rejig `rustc_with_all_queries!`) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs) - #153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute) - #153293 (library: std: process: skip tests on Hermit) - #153301 (Do not ping kobzol on rustc-dev-guide changes)

@Zalathar

Rollup merge of #153161 - nnethercote:rejig-rustc_with_all_queries, r=Zalathar Rejig `rustc_with_all_queries!` There are three things relating to `rustc_with_all_queries!` that have been bugging me. - `rustc_with_all_queries!`'s ability to receive `extra_fake_queries` lines like `[] fn Null(()) -> (),` where the only real thing is the `Null`, and everything is just pretending to be a normal query, ugh. - `make_dep_kind_array!`: a macro produced by one macro (`define_dep_nodes!`) and used by another macro (`define_queries!`) in another crate, ugh. - The `_dep_kind_vtable_ctors` module, which is a special module with no actual code that serves just a way of collecting vtable constructors from two different places so they can be referred to by `make_dep_kind_array!`, ugh. By making some adjustments to how `rustc_with_all_queries!` works, all three of these things are eliminated. r? @Zalathar

JonathanBrouwer · 2026-03-03T08:34:24Z

@rust-timer build 2168ca5

rust-timer · 2026-03-03T09:53:39Z

Finished benchmarking commit (2168ca5): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.0%	[0.0%, 0.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.1%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary -1.0%, secondary -2.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.4%	[3.1%, 3.6%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-9.6%	[-9.6%, -9.6%]	1
Improvements ✅ (secondary)	-2.7%	[-4.3%, -1.1%]	2
All ❌✅ (primary)	-1.0%	[-9.6%, 3.6%]	3

Cycles

Results (secondary 5.6%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	5.6%	[4.5%, 6.8%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 480.113s -> 477.631s (-0.52%)
Artifact size: 396.96 MiB -> 394.94 MiB (-0.51%)

Zoxc · 2026-03-04T03:55:29Z

compiler/rustc_middle/src/queries.rs

+    //-----------------------------------------------------------------------------
+
+    /// We use this for most things when incr. comp. is turned off.
+    non_query Null


non_query seems quite odd to me. I'd probably prefer just dep_kind.

rustbot assigned Zalathar Feb 27, 2026

Zalathar reviewed Feb 27, 2026

View reviewed changes

compiler/rustc_macros/src/query.rs Outdated Show resolved Hide resolved

Zalathar reviewed Feb 27, 2026

View reviewed changes

compiler/rustc_query_impl/src/dep_kind_vtables.rs Outdated Show resolved Hide resolved

This comment has been minimized.

Sign in to view

nnethercote force-pushed the rejig-rustc_with_all_queries branch from 536063f to a295046 Compare March 1, 2026 10:59

This comment has been minimized.

Sign in to view

nnethercote force-pushed the rejig-rustc_with_all_queries branch from a295046 to 92684c9 Compare March 1, 2026 22:06