Skip to content

Conversation

@Zalathar
Copy link
Member

@Zalathar Zalathar commented Feb 1, 2026

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 rustbot added A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Feb 1, 2026
@rustbot
Copy link
Collaborator

rustbot commented Feb 1, 2026

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

#[derive(Default)]
struct HelperTokenStreams {
descs_stream: proc_macro2::TokenStream,
cache_on_disk_if_fns_stream: proc_macro2::TokenStream,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@rustbot

This comment has been minimized.

@Zalathar Zalathar force-pushed the cache-on-disk branch 2 times, most recently from 3820de3 to d24c1a0 Compare February 3, 2026 01:26

// FIXME(Zalathar): Instead of declaring these functions directly, can
// we put them in a macro and then expand that macro downstream in
// `rustc_query_impl`, where the functions are actually used?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@rust-bors

This comment has been minimized.

@rustbot

This comment has been minimized.

@rust-bors

This comment has been minimized.

@rustbot
Copy link
Collaborator

rustbot commented Feb 5, 2026

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
Copy link
Member

tiif commented Feb 8, 2026

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

@rustbot rustbot assigned TaKO8Ki and unassigned tiif Feb 8, 2026
@TaKO8Ki
Copy link
Member

TaKO8Ki commented Feb 10, 2026

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

@bors r+ rollup=never

@rust-bors
Copy link
Contributor

rust-bors bot commented Feb 10, 2026

📌 Commit 892665b has been approved by TaKO8Ki

It is now in the queue for this repository.

@rust-bors rust-bors bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 10, 2026
@rust-bors

This comment has been minimized.

@rust-bors rust-bors bot added merged-by-bors This PR was explicitly merged by bors. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Feb 11, 2026
@rust-bors
Copy link
Contributor

rust-bors bot commented Feb 11, 2026

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

@rust-bors rust-bors bot merged commit 7b25457 into rust-lang:main Feb 11, 2026
12 checks passed
@rustbot rustbot added this to the 1.95.0 milestone Feb 11, 2026
@Zalathar Zalathar deleted the cache-on-disk branch February 11, 2026 00:58
@github-actions
Copy link
Contributor

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.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (7b25457): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

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

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: 476.965s -> 476.905s (-0.01%)
Artifact size: 398.02 MiB -> 398.04 MiB (0.01%)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) merged-by-bors This PR was explicitly merged by bors. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants