add a cache to the `WfPredicates` visitor by sjwang05 · Pull Request #161274 · rust-lang/rust

sjwang05 · 2026-08-18T05:18:53Z

Part of speeding up compiling ReShell with -Znext-solver, see rust-lang/trait-system-refactor-initiative#272 and #t-types/trait-system-refactor > more `reshell` slowness.

The PR changes the WfPredicates visitor to only collect new bounds for unique types. That is, if we have a type like:

type T0 = Map<Then<Whitespace, Whitespace>>
type T1 = Map<Then<T0, T0>>
type T2 = Map<Then<T1, T1>>
...
type T_N = Map<Then<T_N-1, T_N-1>>

etc., the visitor used to end up collecting one WF obligation for each path from T_N to its Whitespace leaves, even though WF of a type (I believe) doesn't depend on the path the visitor took to get there, which allows us to deduplicate by Ty. Not deduplicating caused us to go O(2^N) here.

next-solver is still about ~5x slower than the old solver on the third reproducer due to some other hidden quadratics, and fixing that seems to be more involved, but I think this PR will still be ✨ An Improvement.

r? lcnr

rustbot · 2026-08-18T05:18:56Z

changes to the core type system

cc @lcnr

lcnr · 2026-08-19T15:05:57Z

@@ -5,6 +5,7 @@

 use std::iter;

+use rustc_data_structures::fx::FxHashSet;


something something comparing this to DelayedSet 🤔

I would expect WF to mostly be for quite small types

View changes since the review

lcnr

these UI tests you've added do compile even without this fix, don't they? They are just really slow. I am worried about using UI tests here as it's hard to deal with them again. I would instead prefer adding these as secondary benchmarks, cc @rust-lang/wg-compiler-performance

View changes since this review

lcnr · 2026-08-19T15:09:58Z

    ) -> Result<Option<I::Const>, RerunNonErased> {
        if self.typing_mode().is_erased_not_coherence() {
-            match self.opaque_accesses.rerun_always(RerunReason::EvaluateConst)? {}
+            let resolved = self.resolve_vars_if_possible(alias_const);


@jdonszelmann mind taking this over?

We originally bailed here because we didnt want to deal with the exact behavior of evaluate_const and how it accesses the TypingMode/opaque type storage. also cc https://rust-lang.zulipchat.com/#narrow/channel/260443-project-const-generics/topic/.60evaluate_const.60.20is.20scary/near/617438696 @BoxyUwU @zedddie as we're changing evaluate const to a next-solver only method at which point handling ErasedNonCoherence correctly becomes even easier 🤔

would you mind moving this change out of this PR as the other one feels a lot easier to merge :>

View changes since the review

panstromek · 2026-08-19T15:11:40Z

Let's check whether this is visible on our current benchmarks. If not, then yes, it'd be nice to add new secondary one for this.

@bors try @rust-timer queue

speed up next-solver on some pathological cases

rust-bors · 2026-08-19T16:10:41Z

☀️ Try build successful (CI)
Build commit: 71c2d57 (71c2d570c2e8b858bf22783f39e7bfb4d503968d)
Base parent: f7d782a (f7d782a3be46d6bb4b9792fe69a61db389ba1769)

rust-timer · 2026-08-19T16:53:06Z

Finished benchmarking commit (71c2d57): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@bors rollup=never rustc-perf
@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.3%	[0.1%, 0.4%]	48
Regressions ❌ (secondary)	0.3%	[0.2%, 0.5%]	39
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.6%	[-2.0%, -0.1%]	32
All ❌✅ (primary)	0.3%	[0.1%, 0.4%]	48

Max RSS (memory usage)

Results (primary 0.7%, secondary -2.5%)

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

	mean	range	count
Regressions ❌ (primary)	2.6%	[2.6%, 2.6%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.2%	[-1.2%, -1.2%]	1
Improvements ✅ (secondary)	-2.5%	[-2.7%, -2.3%]	2
All ❌✅ (primary)	0.7%	[-1.2%, 2.6%]	2

Cycles

This perf run didn't have relevant results for this metric.

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 456.256s -> 457.184s (0.20%)
Artifact size: 398.95 MiB -> 398.94 MiB (-0.00%)

nnethercote · 2026-08-19T20:17:30Z

If we do add a secondary benchmark we should do it with intention. We probably have multiple pathological cases for the new trait solver. It would be good to gather them into a single benchmark rather than adding, say, five new tiny benchmarks. The ctfe-stress benchmark is an example where this has been done in the past.

sjwang05 · 2026-08-20T03:46:19Z

Ooh, interesting perf. For now, I got rid of the 2 uitests and the second commit, and replaced the FxHashSet with a DelayedSet. The const eval PR is here: #161380

lcnr · 2026-08-20T12:01:19Z

@bors try @rust-timer queue

speed up next-solver on some pathological cases

rust-bors · 2026-08-20T13:06:00Z

☀️ Try build successful (CI)
Build commit: bd53954 (bd539541bc2d1fed4d588ce4064f9dd86c2b8544)
Base parent: f7d782a (f7d782a3be46d6bb4b9792fe69a61db389ba1769)

rust-timer · 2026-08-20T13:47:50Z

Finished benchmarking commit (bd53954): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

@bors rollup=never rustc-perf
@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
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.5%	[-1.1%, -0.2%]	11
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary -2.1%)

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

Cycles

Results (primary 2.1%, secondary 2.9%)

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

	mean	range	count
Regressions ❌ (primary)	2.1%	[2.1%, 2.1%]	1
Regressions ❌ (secondary)	2.9%	[2.9%, 2.9%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.1%	[2.1%, 2.1%]	1

Binary size

Results (primary -0.0%, secondary -0.0%)

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

Bootstrap: 456.256s -> 456.614s (0.08%)
Artifact size: 398.95 MiB -> 398.92 MiB (-0.01%)

lcnr · 2026-08-21T07:33:40Z

@bors r+

rust-bors · 2026-08-21T07:33:43Z

📌 Commit 4a582e4 has been approved by lcnr

It is now in the queue for this repository.

rust-bors · 2026-08-22T10:17:17Z

☀️ Test successful - CI
Approved by: lcnr
Duration: 2h 56m 49s
Pushing def3ee9 to main...

github-actions · 2026-08-22T10:19:55Z

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 8536f4d (parent) -> def3ee9 (this PR)

Test differences

Show 12 test diffs

12 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 def3ee9e4f0fe1429574f402bb624439bbd13fc6 --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

optional-x86_64-gnu-autodiff: 33m 37s -> 52m 14s (+55.4%)
x86_64-gnu-stable: 1h 44m -> 2h 32m (+45.7%)
x86_64-gnu-llvm-21: 39m 16s -> 54m 57s (+39.9%)
i686-msvc-1: 2h 3m -> 2h 50m (+38.2%)
x86_64-gnu: 1h 49m -> 2h 30m (+37.5%)
dist-various-1: 53m 8s -> 33m 18s (-37.3%)
x86_64-gnu-gcc-core-tests: 10m 50s -> 14m 36s (+34.8%)
x86_64-gnu-llvm-21-1: 42m 26s -> 57m 6s (+34.6%)
x86_64-msvc-ext2: 1h 47m -> 1h 11m (-33.3%)
pr-check-2: 31m 55s -> 42m 11s (+32.2%)

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 · 2026-08-22T11:13:07Z

Finished benchmarking commit (def3ee9): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -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
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.5%	[-0.9%, -0.1%]	10
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary -1.2%)

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

	mean	range	count
Regressions ❌ (primary)	0.6%	[0.6%, 0.6%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-3.0%	[-3.0%, -3.0%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-1.2%	[-3.0%, 0.6%]	2

Cycles

Results (primary -2.5%, secondary 2.3%)

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

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 468.334s -> 468.743s (0.09%)
Artifact size: 400.18 MiB -> 400.28 MiB (0.02%)

@lcnr

…donszelmann only rerun const eval in next-solver if the const actually references opaques Split off from rust-lang#161274: rust-lang#161274 (comment) Previously, we would unconditionally rerun eval if we were in ErasedNotCoherence mode, even if the const's eval result wouldn't depend on the TypingMode. This caused a slowdown with large types whose nested goals contained normalization goals involving types with anon assoc consts, since normalizing needs to evaluate those consts, which can't be done in ErasedNotCoherence mode, causing those goals, and all their parent goals, to be reevaluated. For instance, if we had a large tuple with N elements in a goal, and each of the N elements had such a normalization goal, this would cause us to go quadratic, as is the case here: rust-lang/trait-system-refactor-initiative#272 (comment) With this PR, we only retry const eval if the const's generics actually depend on any opaques which ErasedNotCoherence would influence. We also bail if gce is enabled, since not doing so causes us to ICE. next-solver is still 5x-ish slower than old solver on rust-lang/trait-system-refactor-initiative#272 (comment) due to some other ✨ Hidden Quadratics somewhere, but this PR improves perf on that specific reproducer by about 3x. cc @lcnr, @jdonszelmann

@lcnr

…donszelmann only rerun const eval in next-solver if the const actually references opaques Split off from rust-lang#161274: rust-lang#161274 (comment) Previously, we would unconditionally rerun eval if we were in ErasedNotCoherence mode, even if the const's eval result wouldn't depend on the TypingMode. This caused a slowdown with large types whose nested goals contained normalization goals involving types with anon assoc consts, since normalizing needs to evaluate those consts, which can't be done in ErasedNotCoherence mode, causing those goals, and all their parent goals, to be reevaluated. For instance, if we had a large tuple with N elements in a goal, and each of the N elements had such a normalization goal, this would cause us to go quadratic, as is the case here: rust-lang/trait-system-refactor-initiative#272 (comment) With this PR, we only retry const eval if the const's generics actually depend on any opaques which ErasedNotCoherence would influence. We also bail if gce is enabled, since not doing so causes us to ICE. next-solver is still 5x-ish slower than old solver on rust-lang/trait-system-refactor-initiative#272 (comment) due to some other ✨ Hidden Quadratics somewhere, but this PR improves perf on that specific reproducer by about 3x. cc @lcnr, @jdonszelmann

@lcnr

…donszelmann only rerun const eval in next-solver if the const actually references opaques Split off from rust-lang#161274: rust-lang#161274 (comment) Previously, we would unconditionally rerun eval if we were in ErasedNotCoherence mode, even if the const's eval result wouldn't depend on the TypingMode. This caused a slowdown with large types whose nested goals contained normalization goals involving types with anon assoc consts, since normalizing needs to evaluate those consts, which can't be done in ErasedNotCoherence mode, causing those goals, and all their parent goals, to be reevaluated. For instance, if we had a large tuple with N elements in a goal, and each of the N elements had such a normalization goal, this would cause us to go quadratic, as is the case here: rust-lang/trait-system-refactor-initiative#272 (comment) With this PR, we only retry const eval if the const's generics actually depend on any opaques which ErasedNotCoherence would influence. We also bail if gce is enabled, since not doing so causes us to ICE. next-solver is still 5x-ish slower than old solver on rust-lang/trait-system-refactor-initiative#272 (comment) due to some other ✨ Hidden Quadratics somewhere, but this PR improves perf on that specific reproducer by about 3x. cc @lcnr, @jdonszelmann

@lcnr

…donszelmann only rerun const eval in next-solver if the const actually references opaques Split off from rust-lang#161274: rust-lang#161274 (comment) Previously, we would unconditionally rerun eval if we were in ErasedNotCoherence mode, even if the const's eval result wouldn't depend on the TypingMode. This caused a slowdown with large types whose nested goals contained normalization goals involving types with anon assoc consts, since normalizing needs to evaluate those consts, which can't be done in ErasedNotCoherence mode, causing those goals, and all their parent goals, to be reevaluated. For instance, if we had a large tuple with N elements in a goal, and each of the N elements had such a normalization goal, this would cause us to go quadratic, as is the case here: rust-lang/trait-system-refactor-initiative#272 (comment) With this PR, we only retry const eval if the const's generics actually depend on any opaques which ErasedNotCoherence would influence. We also bail if gce is enabled, since not doing so causes us to ICE. next-solver is still 5x-ish slower than old solver on rust-lang/trait-system-refactor-initiative#272 (comment) due to some other ✨ Hidden Quadratics somewhere, but this PR improves perf on that specific reproducer by about 3x. cc @lcnr, @jdonszelmann

@lcnr

…donszelmann only rerun const eval in next-solver if the const actually references opaques Split off from rust-lang#161274: rust-lang#161274 (comment) Previously, we would unconditionally rerun eval if we were in ErasedNotCoherence mode, even if the const's eval result wouldn't depend on the TypingMode. This caused a slowdown with large types whose nested goals contained normalization goals involving types with anon assoc consts, since normalizing needs to evaluate those consts, which can't be done in ErasedNotCoherence mode, causing those goals, and all their parent goals, to be reevaluated. For instance, if we had a large tuple with N elements in a goal, and each of the N elements had such a normalization goal, this would cause us to go quadratic, as is the case here: rust-lang/trait-system-refactor-initiative#272 (comment) With this PR, we only retry const eval if the const's generics actually depend on any opaques which ErasedNotCoherence would influence. We also bail if gce is enabled, since not doing so causes us to ICE. next-solver is still 5x-ish slower than old solver on rust-lang/trait-system-refactor-initiative#272 (comment) due to some other ✨ Hidden Quadratics somewhere, but this PR improves perf on that specific reproducer by about 3x. cc @lcnr, @jdonszelmann

@lcnr

Rollup merge of #161380 - sjwang05:retry-consteval-less, r=jdonszelmann only rerun const eval in next-solver if the const actually references opaques Split off from #161274: #161274 (comment) Previously, we would unconditionally rerun eval if we were in ErasedNotCoherence mode, even if the const's eval result wouldn't depend on the TypingMode. This caused a slowdown with large types whose nested goals contained normalization goals involving types with anon assoc consts, since normalizing needs to evaluate those consts, which can't be done in ErasedNotCoherence mode, causing those goals, and all their parent goals, to be reevaluated. For instance, if we had a large tuple with N elements in a goal, and each of the N elements had such a normalization goal, this would cause us to go quadratic, as is the case here: rust-lang/trait-system-refactor-initiative#272 (comment) With this PR, we only retry const eval if the const's generics actually depend on any opaques which ErasedNotCoherence would influence. We also bail if gce is enabled, since not doing so causes us to ICE. next-solver is still 5x-ish slower than old solver on rust-lang/trait-system-refactor-initiative#272 (comment) due to some other ✨ Hidden Quadratics somewhere, but this PR improves perf on that specific reproducer by about 3x. cc @lcnr, @jdonszelmann

@lcnr

only rerun const eval in next-solver if the const actually references opaques Split off from rust-lang/rust#161274: rust-lang/rust#161274 (comment) Previously, we would unconditionally rerun eval if we were in ErasedNotCoherence mode, even if the const's eval result wouldn't depend on the TypingMode. This caused a slowdown with large types whose nested goals contained normalization goals involving types with anon assoc consts, since normalizing needs to evaluate those consts, which can't be done in ErasedNotCoherence mode, causing those goals, and all their parent goals, to be reevaluated. For instance, if we had a large tuple with N elements in a goal, and each of the N elements had such a normalization goal, this would cause us to go quadratic, as is the case here: rust-lang/trait-system-refactor-initiative#272 (comment) With this PR, we only retry const eval if the const's generics actually depend on any opaques which ErasedNotCoherence would influence. We also bail if gce is enabled, since not doing so causes us to ICE. next-solver is still 5x-ish slower than old solver on rust-lang/trait-system-refactor-initiative#272 (comment) due to some other ✨ Hidden Quadratics somewhere, but this PR improves perf on that specific reproducer by about 3x. cc @lcnr, @jdonszelmann

@lcnr

only rerun const eval in next-solver if the const actually references opaques Split off from rust-lang/rust#161274: rust-lang/rust#161274 (comment) Previously, we would unconditionally rerun eval if we were in ErasedNotCoherence mode, even if the const's eval result wouldn't depend on the TypingMode. This caused a slowdown with large types whose nested goals contained normalization goals involving types with anon assoc consts, since normalizing needs to evaluate those consts, which can't be done in ErasedNotCoherence mode, causing those goals, and all their parent goals, to be reevaluated. For instance, if we had a large tuple with N elements in a goal, and each of the N elements had such a normalization goal, this would cause us to go quadratic, as is the case here: rust-lang/trait-system-refactor-initiative#272 (comment) With this PR, we only retry const eval if the const's generics actually depend on any opaques which ErasedNotCoherence would influence. We also bail if gce is enabled, since not doing so causes us to ICE. next-solver is still 5x-ish slower than old solver on rust-lang/trait-system-refactor-initiative#272 (comment) due to some other ✨ Hidden Quadratics somewhere, but this PR improves perf on that specific reproducer by about 3x. cc @lcnr, @jdonszelmann

rustbot added 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. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) labels Aug 18, 2026

rustbot assigned lcnr Aug 18, 2026