only rerun const eval in next-solver if the const actually references opaques - #161380

sjwang05 · 2026-08-20T03:55:40Z

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

rustbot · 2026-08-20T03:55:45Z

r? @Enselic

rustbot has assigned @Enselic.
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

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler
compiler expanded to 75 candidates
Random selection from 18 candidates

Enselic · 2026-08-20T14:08:42Z

r? lcnr since you were the one that requested a separate PR for this.

lcnr · 2026-09-08T12:29:53Z

r? jdonszelmann

rustbot · 2026-09-08T12:29:58Z

jdonszelmann is currently at their maximum review capacity.
They may take a while to respond.

jdonszelmann · 2026-09-14T13:47:03Z

I think this pr has a soft conflict with the renames in #162126. r=me,khyperia once resolved

rustbot · 2026-09-16T17:06:54Z

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.

sjwang05 · 2026-09-16T18:46:17Z

Done 👍

sjwang05 · 2026-10-01T03:14:39Z

Hi @khyperia @jdonszelmann, if either of y'all have the time, can you r+ this PR for me?

jdonszelmann · 2026-10-01T05:44:43Z

@bors r+

Sorry , I did remember looking at your pr earlier but it slipped through it seems looks like a nice change.

rust-bors · 2026-10-01T05:44:46Z

📌 Commit d7cf3cb has been approved by jdonszelmann

It is now in the queue for this repository.

JonathanBrouwer · 2026-10-01T06:33:58Z

@bors try @rust-timer queue

only rerun const eval in next-solver if the const actually references opaques

rust-bors · 2026-10-01T07:50:15Z

☀️ Try build successful (CI)
Build commit: afd9b22 (afd9b22dd5f2a65cb5983cb984dd6f002dbb5976)
Base parent: 012c0bd (012c0bd4d516934012c9a1ecb26e9eb283d2ed75)

@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

…uwer Rollup of 9 pull requests Successful merges: - #163483 (Bump bootstrap compiler to 1.100.0 beta) - #161380 (only rerun const eval in next-solver if the const actually references opaques) - #162900 (Some refactorings around metadata encoding) - #163580 (Provide better doc code example for `UnixDatagram::bind_addr` and `UnixListener::bind_addr`) - #163584 ([triagebot] Ping me for debugger visualizer changes) - #162782 (Fix rustdoc ICE caused by mishandling of ambiguity errors) - #163314 (move `#[macro_export]` on declarative macro check to `rustc_attr_parsing`) - #163405 (Remove some #[linkage] options) - #163581 (do not suggest precise capturing when the opaque span is in a macro expansion)

@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

rust-timer · 2026-10-01T11:55:02Z

Finished benchmarking commit (afd9b22): comparison URL.

Overall result: ❌ regressions - no action needed

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

@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.3%	[0.3%, 0.3%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (secondary -3.4%)

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

Cycles

Results (primary 2.7%)

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

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

Binary size

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

Bootstrap: 490.746s -> 488.16s (-0.53%)
Artifact size: 406.55 MiB -> 406.51 MiB (-0.01%)

Rollup of 11 pull requests Successful merges: - #163483 (Bump bootstrap compiler to 1.100.0 beta) - #161380 (only rerun const eval in next-solver if the const actually references opaques) - #162900 (Some refactorings around metadata encoding) - #163580 (Provide better doc code example for `UnixDatagram::bind_addr` and `UnixListener::bind_addr`) - #163584 ([triagebot] Ping me for debugger visualizer changes) - #162904 (Fix ICE for ambiguous candidates on method probing) - #163281 (Add `f16` inline ASM support to `spirv.rs`) - #163314 (move `#[macro_export]` on declarative macro check to `rustc_attr_parsing`) - #163405 (Remove some #[linkage] options) - #163530 (`const impl PartialEq` for `f16b`) - #163581 (do not suggest precise capturing when the opaque span is in a macro expansion)

…uwer Rollup of 20 pull requests Successful merges: - #163483 (Bump bootstrap compiler to 1.100.0 beta) - #161380 (only rerun const eval in next-solver if the const actually references opaques) - #162900 (Some refactorings around metadata encoding) - #163461 (Improve diagnostic deduplication) - #163580 (Provide better doc code example for `UnixDatagram::bind_addr` and `UnixListener::bind_addr`) - #163584 ([triagebot] Ping me for debugger visualizer changes) - #159021 (windows-gnu: enable native TLS) - #161467 (wfcheck: name the item that discards an unused type parameter) - #162618 (trait_selection: Preserve eager normalization failures) - #162904 (Fix ICE for ambiguous candidates on method probing) - #163064 (Avoid computing overflowed goal chains for crate dependencies) - #163281 (Add `f16` inline ASM support to `spirv.rs`) - #163314 (move `#[macro_export]` on declarative macro check to `rustc_attr_parsing`) - #163360 ([rustdoc] Correctly handle rustc_allow_incoherent_impl on primitive methods) - #163385 (GVN transmutes of Immediate::Uninit to Immediate::Uninit) - #163405 (Remove some #[linkage] options) - #163530 (`const impl PartialEq` for `f16b`) - #163581 (do not suggest precise capturing when the opaque span is in a macro expansion) - #163590 (Make `AllocatorNightly` less clever) - #163599 (Add union pattern reference change to relnotes)

@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

…uwer Rollup of 20 pull requests Successful merges: - rust-lang/rust#163483 (Bump bootstrap compiler to 1.100.0 beta) - rust-lang/rust#161380 (only rerun const eval in next-solver if the const actually references opaques) - rust-lang/rust#162900 (Some refactorings around metadata encoding) - rust-lang/rust#163461 (Improve diagnostic deduplication) - rust-lang/rust#163580 (Provide better doc code example for `UnixDatagram::bind_addr` and `UnixListener::bind_addr`) - rust-lang/rust#163584 ([triagebot] Ping me for debugger visualizer changes) - rust-lang/rust#159021 (windows-gnu: enable native TLS) - rust-lang/rust#161467 (wfcheck: name the item that discards an unused type parameter) - rust-lang/rust#162618 (trait_selection: Preserve eager normalization failures) - rust-lang/rust#162904 (Fix ICE for ambiguous candidates on method probing) - rust-lang/rust#163064 (Avoid computing overflowed goal chains for crate dependencies) - rust-lang/rust#163281 (Add `f16` inline ASM support to `spirv.rs`) - rust-lang/rust#163314 (move `#[macro_export]` on declarative macro check to `rustc_attr_parsing`) - rust-lang/rust#163360 ([rustdoc] Correctly handle rustc_allow_incoherent_impl on primitive methods) - rust-lang/rust#163385 (GVN transmutes of Immediate::Uninit to Immediate::Uninit) - rust-lang/rust#163405 (Remove some #[linkage] options) - rust-lang/rust#163530 (`const impl PartialEq` for `f16b`) - rust-lang/rust#163581 (do not suggest precise capturing when the opaque span is in a macro expansion) - rust-lang/rust#163590 (Make `AllocatorNightly` less clever) - rust-lang/rust#163599 (Add union pattern reference change to relnotes)

rustbot assigned Enselic Aug 20, 2026

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 20, 2026

sjwang05 mentioned this pull request Aug 20, 2026

add a cache to the WfPredicates visitor #161274

Merged

rustbot assigned lcnr and unassigned Enselic Aug 20, 2026

khyperia reviewed Aug 26, 2026

View reviewed changes

Comment thread compiler/rustc_next_trait_solver/src/solve/eval_ctxt/mod.rs Outdated

sjwang05 force-pushed the retry-consteval-less branch from fdc158e to e76a75f Compare August 27, 2026 19:18

rustbot assigned jdonszelmann and unassigned lcnr Sep 8, 2026

only rerun const eval if the const actually references opaques

d7cf3cb

sjwang05 force-pushed the retry-consteval-less branch from e76a75f to d7cf3cb Compare September 16, 2026 17:06

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 1, 2026

This comment has been minimized.

Sign in to view

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

This comment has been minimized.

Sign in to view

rust-bors Bot pushed a commit that referenced this pull request Oct 1, 2026

Auto merge of #161380 - sjwang05:retry-consteval-less, r=<try>

afd9b22

only rerun const eval in next-solver if the const actually references opaques

This comment has been minimized.

Sign in to view

JonathanBrouwer mentioned this pull request Oct 1, 2026

Rollup of 9 pull requests #163595

Closed

JonathanBrouwer mentioned this pull request Oct 1, 2026

Rollup of 9 pull requests #163596

Closed

GuillaumeGomez mentioned this pull request Oct 1, 2026

Rollup of 10 pull requests #163600

Closed

GuillaumeGomez mentioned this pull request Oct 1, 2026

Rollup of 11 pull requests #163601

Closed

rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Oct 1, 2026

JonathanBrouwer mentioned this pull request Oct 1, 2026

Rollup of 20 pull requests #163609

Merged

rust-bors Bot merged commit 2b32612 into rust-lang:main Oct 2, 2026
14 checks passed

rustbot added this to the 1.101.0 milestone Oct 2, 2026

Uh oh!

Conversation

sjwang05 commented Aug 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Aug 20, 2026

Uh oh!

Enselic commented Aug 20, 2026

Uh oh!

Uh oh!

lcnr commented Sep 8, 2026

Uh oh!

rustbot commented Sep 8, 2026

Uh oh!

jdonszelmann commented Sep 14, 2026

Uh oh!

rustbot commented Sep 16, 2026

Uh oh!

sjwang05 commented Sep 16, 2026

Uh oh!

sjwang05 commented Oct 1, 2026

Uh oh!

jdonszelmann commented Oct 1, 2026

Uh oh!

rust-bors Bot commented Oct 1, 2026

Uh oh!

JonathanBrouwer commented Oct 1, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

rust-bors Bot commented Oct 1, 2026

Uh oh!

This comment has been minimized.

rust-timer commented Oct 1, 2026

Overall result: ❌ regressions - no action needed

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

sjwang05 commented Aug 20, 2026 •

edited

Loading