Clean up query macros for cache_on_disk_if

[Zalathar]

This PR aims to make the macros for dealing with cache_on_disk_if a bit easier to read and work with.

There should be no change to compiler behaviour.

[rustbot]

r? @tiif

rustbot has assigned @tiif.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[petrochenkov]

Is there multiple functions/descriptions, or one function/description?
There's some naming inconsistency, query_description_stream below says that it's one, but "descs" says that there are multiple.

[Zalathar]

Each stream contains multiple descriptions or multiple functions (0-1 of each per query).

The existing name query_description_stream is misleading; I'll update this PR to change it.

[Zoxc]

We kind of want to keep rustc_query_impl small (for compile-time reasons), so having it point to functions (which won't be inlined) in rustc_middle isn't terrible.

[Zalathar]

I was thinking that we also want to keep rustc_middle small (since it's a bottleneck for most other compiler crates), though I don't have a strong sense of how shuffling things between the two crates affects overall build times (especially with metadata pipelining).

[Zoxc]

Yes, but there's other way to reduce rustc_middle (particularly if other crates can also define queries). rustc_query_impl will mostly keep growing as we add queries.

[Zalathar]

The primary purpose of rustc_query_impl is to allow rustc_middle to be smaller.

If we wanted to improve query-impl build times by enabling more parallelism, we wouldn't do so by moving code into middle; we'd move it into an intermediate crate between the two.

So I don't think keeping query-impl small is a reason to not move code from middle to query-impl.

[rustbot]

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.

[tiif]

Hi, sorry for taking a while to get to this. I took a while to read this and while I am fairly confident that the logic hasn't changed much, I am not familiar enough with this part of the compiler to approve the change.

@rustbot reroll

[TaKO8Ki]

I have confirmed it does not change the current compiler behavior.

@bors r+ rollup=never

[rust-bors]

📌 Commit 892665b has been approved by TaKO8Ki

It is now in the queue for this repository.

[rust-bors]

☀️ Test successful - CI
Approved by: TaKO8Ki
Duration: 4h 6s
Pushing 7b25457 to main...

[github-actions]

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 9e79395 (parent) -> 7b25457 (this PR)

Test differences

Show 2 test diffs

2 doctest diffs were found. These are ignored, as they are noisy.

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 7b25457166468840db16998f507296675f0e07a0 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

1. dist-x86_64-apple: 3h 40m -> 2h 17m (-37.6%)
2. dist-aarch64-llvm-mingw: 1h 37m -> 1h 55m (+19.3%)
3. x86_64-gnu-debug: 1h 55m -> 2h 6m (+10.2%)
4. x86_64-mingw-1: 2h 56m -> 2h 39m (-9.3%)
5. dist-x86_64-illumos: 1h 48m -> 1h 39m (-8.5%)
6. x86_64-msvc-1: 2h 38m -> 2h 25m (-8.1%)
7. i686-msvc-1: 3h 3m -> 2h 48m (-8.1%)
8. x86_64-msvc-2: 2h 33m -> 2h 21m (-7.9%)
9. aarch64-gnu-llvm-20-2: 49m 19s -> 52m 49s (+7.1%)
10. dist-aarch64-msvc: 1h 39m -> 1h 32m (-7.0%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.