Clarify aspects of query macros by nnethercote · Pull Request #152779 · rust-lang/rust

nnethercote · 2026-02-18T02:41:49Z

Various clarity and consistency improvements to query macros.

r? @Zalathar

rustbot · 2026-02-18T02:41:55Z

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

nnethercote · 2026-02-18T02:42:09Z

@bors try @rust-timer queue

…r=<try> Clarify aspects of query macros

compiler/rustc_middle/src/query/plumbing.rs

rust-bors · 2026-02-18T04:53:34Z

☀️ Try build successful (CI)
Build commit: e5069e4 (e5069e4a7bbe127f356e04aafb5c8bd91f065b40, parent: 8387095803f21a256a9a772ac1f9b41ed4d5aa0a)

rust-timer · 2026-02-18T05:33:56Z

Finished benchmarking commit (e5069e4): 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 6.8%, secondary -5.3%)

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

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

Cycles

Results (primary -2.5%)

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)	-	-	0
Improvements ✅ (primary)	-2.5%	[-2.5%, -2.5%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.5%	[-2.5%, -2.5%]	1

Binary size

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

Bootstrap: 480.396s -> 483.06s (0.55%)
Artifact size: 397.88 MiB -> 397.83 MiB (-0.01%)

nnethercote · 2026-02-18T09:37:46Z

I have updated. I addressed most of the comments; two of them I left unresolved that I don't think warrant changes.

Zalathar · 2026-02-18T13:15:13Z

My sticking point is applying impl IntoQueryParam to all queries, which I think is an unacceptable regression.

I did find a way to simplify $($K:tt)* to just $K:tt, by having the proc-macro surround key types with parentheses. That gets most of the benefit with much less downside; I intend to write up the details tomorrow.

nnethercote · 2026-02-18T21:22:09Z

Ok, can you tell me which commits I should remove?

nnethercote · 2026-02-19T23:36:16Z

I have updated. The commits relating to IntoQueryParam are gone. There is one new commit that reduces $K and $V usage in some simple ways.

There are six small macros used in `define_callbacks` that all expand to one thing if a particular query modifier is present, and to another thing otherwise. One of these macros looks for the `arena_cache` modifier: - `query_if_arena` Two of these macros look for the `return_result_from_ensure_ok` modifier: - `query_ensure_select` - `ensure_ok_result` Three of these macros look for the `separate_provide_extern` modifier: - `local_key_if_separate_extern` - `separate_provide_extern_decl` - `separate_provide_extern_default` (There is also `query_helper_param_ty!`, but it follows a different pattern, and I will deal with it later.) The "one thing"/"another thing" is different for every macro. For most of them you can't see at the macro call site what the expansion will be; you have to look at the macro definition. This is annoying. This commit reduces the six macros into three macros: - `if_arena_cache` - `if_return_result_from_ensure_ok` - `if_separate_provide_extern` They all have the same form: they look for a modifier and then expand to one *given* thing or the other *given* thing. You can see at the call site the two possible expansions, which is much nicer. (Note: `query_if_arena` already had this form.) Ideally there would be a single macro instead of three, but I couldn't work out a way to combine them.

So that all `$( ... $name ... )*` repetitions are spread across multiple lines, even if they all fit on one line. I find this much easier to read because the `$name` repetition is the main feature of these macros.

It doesn't make much sense to put the query doc comments on these structs. (The doc comments *are* put on various query functions, where it makes more sense.)

Within `define_callbacks!`: - Use `Key<'tcx>` where possible instead of `$($K)*`. - Use `Value<'tcx>` where possible instead of `$V`. In the other `define_*!` macros: - Use `$K:ty` where possible instead of `$($K:tt)*`. - Add comments about unused `$K` and `$V` cases. - Add `()` key types to the special nodes in the `define_dep_nodes!` invocation for consistency with normal queries.

rustbot · 2026-02-20T19:34:53Z

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-02-20T19:35:52Z

I have rebased.

I know I have a lot of query PRs in flight right now. If I had a choice I would get this one merged first, because the reindenting in the second commit is conflict-prone.

rustbot assigned Zalathar Feb 18, 2026

This comment has been minimized.

Sign in to view

rust-bors bot pushed a commit that referenced this pull request Feb 18, 2026

Auto merge of #152779 - nnethercote:clarify-aspects-of-query-macros, …

e5069e4

…r=<try> Clarify aspects of query macros

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Feb 18, 2026