Skip to content

Rollup of 7 perf-sensitive pull requests - #165084

Closed
JonathanBrouwer wants to merge 45 commits into
rust-lang:mainfrom
JonathanBrouwer:rollup-MEOKZSt
Closed

JonathanBrouwer wants to merge 45 commits into
rust-lang:mainfrom
JonathanBrouwer:rollup-MEOKZSt

Conversation

@JonathanBrouwer

Copy link
Copy Markdown
Member

Successful merges:

r? @ghost

Create a similar rollup

heiher and others added 30 commits October 3, 2026 20:26
ICX was bumped to 2026.2 on this image which broke the path lookup
…large structs

This improves compile time for crates that derive Debug for large structs (e.g., ripgrep). It also reduces metadata size for some of those.
This avoids one more string and makes the derive code slightly nicer as we don't have to track whether we're on last item
We do this by changing the variable to a closure and only call it when it's needed
In `instantiate_and_apply_query_response`, instantiate the two
instantiatable parts of the response separately. This requires adding a
new method `instantiate_value` to `SolverDelegate` (r-a will need
updating separately) and making a function of the same name in
`rustc_infer` public.

Do a similar thing for `State` in `instantiate_canonical_state`.

This is equivalent behaviour that will enable further changes in
subsequent commits.
Both `unify_query_var_values` call sites are preceded by a call to
`instantiate_value` on the `var_values`. If instantiation changes any of
the elements we end up interning an entirely new list, through
`fold_list`.

This commit changes things so that `unify_query_var_values` does
instantiation on individual elements as it iterates, and avoids having
to intern an entire list. This changes the caching behaviour in some
cases, but overall it's a perf win.
This avoids a lot of calls to `instantiate_value`.
`Response` has `is_identity` and `is_identity_modulo_regions` methods.
These are reasonably hot and traverse the response's `var_values` in
very similar ways. This commit merges these two methods into a single
method that returns a new three-value enum `IsIdentity`. It also
pre-computes that `IsIdentity` for each response and stores it in the
new `Response::var_values_is_identity` field.

This is a perf win because it avoids repeated traversals.
If the response is an identity, and there are no external constraints,
and the response var kinds match the canonical goal var kinds, this
function is a no-op.
It provides a more principled and type-safe way to extract and process
parts of a `Canonical` value.
This updates the rust-version file to 16d1ffa.
The rustc-josh-sync Cronjob Bot and others added 14 commits October 27, 2026 02:46
Some of its functions were stabilized, so it's no longer needed here.
They are like `TokenStream` and `TokenTree`, but with the additional
`AttrTokenTree::AttrsTarget` variant that stores the attributes and
tokens for an attribute target.

This duplication is annoying, and also leads to some inefficiencies
when we have to produce an `AttrTokenStream` only to then convert it to
a `TokenStream`.

The new `LazyAttrTokenStreamInner::to_token_stream_with` takes a
`configure` closure. This closure is passed through various layers down
to `make_token_trees`, where it controls cfg expansion. Callers that
don't do expansion pass a trivial `keep_all` closure.
`try_configure_tokens` passes a non-trivial `configure` closure.

Overall this change makes the code shorter and slightly improves compile
times. One minor behavioural change on an error case: if parse recovery
finishes with an unmatched opening delimiter, `make_token_trees` drops
the caller's preceding trees; the old code kept them. This is obscure
and no existing tests hit it.

The next commit will rename `LazyAttrTokenStream` to `LazyTokenStream`.
It's a separate commit because it is uninteresting churn.
By removing the `Attr`, which is no longer necessary.
In `check_expr_lit`, if we have an integer literal and the expected type
is an integer type var, we currently create a new type var that is later
unified with the expected one. This commit changes it to just reuse the
existing expected one. This avoids lots of unnecessary integer type var
creation and unification. (And likewise for float type vars.)

This is a big win on `deep-vector`, but it doesn't help with other
benchmarks, unfortunately.

Only one ui test is changed, for the better:

- Previously it printed `{integer}` because there were two distinct
  integer variables. Now there is one and the types-are-equal error
  message elision occurs and it is shown as `_`. (Same as what you'd see
  if the call was `test(&mut 7i32, &7i32)` with known types.)

- There is now also a useful `help` subdiagnostic.

Given how simple the change is, I think it's worthwhile.
…, r=folkertdev

stdarch subtree update

Subtree update of `stdarch` to rust-lang/stdarch@d01cfec.

Created using https://github.com/rust-lang/josh-sync.

r? @ghost
…rochenkov

Move lang item collection to the resolver

The separate query had to walk the entire ast again, also tracking owners and converting NodeIds to DefIds. I think it's nicer to just do it as part of the resolver.

Alternatively we could limit the lang item collection to the local ones and keep the query. Instead of walking the current crate again we'd just take the list from the resolver query just like we take the list from upstream crates.
New solver opts for `diesel` (part 2)

A sequel to rust-lang#163981. Details in individual commits.

Local measurements:
```
solver         icounts (B)
------         -----------
old            37.9
new (orig)     49.6 (1.31x)
new (this PR)  45.4 (1.20x)
```
Also some small improvements on a range of other benchmarks.

r? @lcnr
…ethercote

perf: emit field names as a concatenated string in derive(Debug) for structs

Similar idea as rust-lang#162535 and previous attempts.

Again, I also noticed that no test fails when I mess up the string, so I added a test case.
Avoid stdlib's `impl Hash for Discriminant` for stable hashing

Of all the different ways we currently leak compiler/stdlib details into stable hashes, relying on `Discriminant::hash` seems high on the list of ones that could cause actual problems in the future.

This PR therefore removes `impl StableHash for Discriminant`, and replaces it with an explicit negative impl as a roadblock to anyone who might unknowingly try to reintroduce the problem.

To make this work, `#[derive(StableHash)]` now invents its own fake discriminant based on the syntactic ordering of enum variants. That should keep the hash values consistent across compiler stages.

In places where we were hashing Discriminant manually, this PR introduces explicit “tag” enums as seen in rust-lang#164458.

---

This change necessarily perturbs the hashes included in legacy-symbol-mangling symbols, as demonstrated in the re-blessed tests. This should be fine, as I believe the exact hash values are considered unstable anyway and have changed in the past.
…type-vars, r=BoxyUwU

Avoid unnecessary numeric type vars

In `check_expr_lit`, if we have an integer literal and the expected type is an integer type var, we currently create a new type var that is later unified with the expected one. This commit changes it to just reuse the existing expected one. This avoids lots of unnecessary integer type var creation and unification. (And likewise for float type vars.)

This is a big win on `deep-vector`, but it doesn't help with other benchmarks, unfortunately.

Only one ui test is changed, for the better:

- Previously it printed `{integer}` because there were two distinct integer variables. Now there is one and the types-are-equal error message elision occurs and it is shown as `_`. (Same as what you'd see if the call was `test(&mut 7i32, &7i32)` with known types.)

- There is now also a useful `help` subdiagnostic.

Given how simple the change is, I think it's worthwhile.

r? @BoxyUwU
…petrochenkov

Remove `AttrTokenStream` and `AttrTokenTree`

These are very similar to `TokenStream` and `TokenTree`, which has annoyed me for a long time. This PR removes them, making the code simpler and a tiny bit faster. Details in individual commits.

r? @petrochenkov
@rust-bors rust-bors Bot added the rollup A PR which is a rollup label Oct 28, 2026
@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 28, 2026
@JonathanBrouwer

Copy link
Copy Markdown
Member Author

@bors r+ p=4 force

Trying commonly failed jobs
@bors try jobs=dist-various-1,test-various,test-x86_64-gnu-aux,test-x86_64-msvc-1,test-aarch64-apple-1,test-aarch64-apple-2,test-x86_64-mingw-1,test-i686-msvc,test-armhf-gnu,test-x86_64-gnu-llvm-22-3,test-aarch64-msvc-2

@rust-bors

rust-bors Bot commented Oct 28, 2026

Copy link
Copy Markdown
Contributor

📌 Commit 6aa974d has been approved by JonathanBrouwer

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 Oct 28, 2026
@rust-bors

This comment has been minimized.

rust-bors Bot pushed a commit that referenced this pull request Oct 28, 2026
Rollup of 7 pull requests


try-job: dist-various-1
try-job: test-various
try-job: test-x86_64-gnu-aux
try-job: test-x86_64-msvc-1
try-job: test-aarch64-apple-1
try-job: test-aarch64-apple-2
try-job: test-x86_64-mingw-1
try-job: test-i686-msvc
try-job: test-armhf-gnu
try-job: test-x86_64-gnu-llvm-22-3
try-job: test-aarch64-msvc-2
@JonathanBrouwer JonathanBrouwer changed the title Rollup of 7 pull requests Rollup of 7 perf-sensitive pull requests Oct 28, 2026
@JonathanBrouwer

JonathanBrouwer commented Oct 28, 2026 •

Copy link
Copy Markdown
Member Author

#165032 is in here so it gets merged faster, as it is p=1

@rust-bors

rust-bors Bot commented Oct 28, 2026

Copy link
Copy Markdown
Contributor

☀️ Try build successful (CI)
Build commit: b6c1ec8 (b6c1ec8542027adc5956faac178821a4c85c776c)
Base parent: 41089d0 (41089d07a0a2afc16adfe28a760d94d73d7298a4)

@rust-bors rust-bors Bot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Oct 28, 2026
@rust-bors

rust-bors Bot commented Oct 28, 2026

Copy link
Copy Markdown
Contributor

☔ The latest upstream changes made this pull request unmergeable. Please resolve the merge conflicts by rebasing.

This pull request was unapproved.

@rustbot rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Oct 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

rollup A PR which is a rollup

Projects

None yet

Development

Successfully merging this pull request may close these issues.

10 participants