`-Znext-solver` Less normalizes-to janks by ShoyuVanilla · Pull Request #156619 · rust-lang/rust

ShoyuVanilla · 2026-05-15T19:20:13Z

View all comments

cc rust-lang/trait-system-refactor-initiative#223 (comment)

r? lcnr

rustbot · 2026-05-15T19:20:17Z

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

changes to inspect_obligations.rs

cc @lcnr

This PR modifies tests/ui/issues/. If this PR is adding new tests to tests/ui/issues/,
please refrain from doing so, and instead add it to more descriptive subdirectories.

ShoyuVanilla · 2026-05-15T19:35:00Z

@bors try @rust-timer queue

`-Znext-solver` Less normalizes-to janks

ShoyuVanilla · 2026-05-15T19:46:09Z

I haven't done the nested goals' recursion depth part yet 😅 I'm gonna work on it if the overall design here pan out to be feasible

rust-bors · 2026-05-15T21:45:37Z

☀️ Try build successful (CI)
Build commit: d4c528b (d4c528b37c59bf04c41ddba6375584d284d1a9ba, parent: 88ba7fbe0a6eda36e0adbfd0482856f3784031b9)

rust-timer · 2026-05-15T23:03:40Z

Finished benchmarking commit (d4c528b): 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
@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.4%	[0.3%, 0.8%]	7
Regressions ❌ (secondary)	22.5%	[0.6%, 46.0%]	12
Improvements ✅ (primary)	-0.3%	[-0.7%, -0.1%]	20
Improvements ✅ (secondary)	-0.3%	[-0.6%, -0.2%]	29
All ❌✅ (primary)	-0.1%	[-0.7%, 0.8%]	27

Max RSS (memory usage)

Results (primary 1.5%, secondary 8.5%)

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

	mean	range	count
Regressions ❌ (primary)	1.5%	[0.9%, 2.6%]	5
Regressions ❌ (secondary)	11.4%	[2.0%, 25.8%]	8
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-14.8%	[-14.8%, -14.8%]	1
All ❌✅ (primary)	1.5%	[0.9%, 2.6%]	5

Cycles

Results (secondary 26.9%)

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)	26.9%	[17.5%, 41.5%]	9
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 510.626s -> 509.733s (-0.17%)
Artifact size: 398.07 MiB -> 398.06 MiB (-0.00%)

ShoyuVanilla · 2026-05-16T00:58:30Z

Oh, the perf regressions are insane 😅 I'll look into them

ShoyuVanilla · 2026-05-16T17:25:25Z

@bors try @rust-timer queue

`-Znext-solver` Less normalizes-to janks

rust-bors · 2026-05-16T19:35:04Z

☀️ Try build successful (CI)
Build commit: 52311d2 (52311d29eb5b4b58f67e481749703829fab93a19, parent: 35143615544ede08a47947901cd4a6b7c5ecd450)

rust-timer · 2026-05-16T20:16:10Z

Finished benchmarking commit (52311d2): 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
@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.8%	[0.2%, 1.2%]	8
Regressions ❌ (secondary)	26.5%	[0.1%, 45.5%]	10
Improvements ✅ (primary)	-0.2%	[-0.3%, -0.1%]	23
Improvements ✅ (secondary)	-0.4%	[-0.8%, -0.2%]	29
All ❌✅ (primary)	0.0%	[-0.3%, 1.2%]	31

Max RSS (memory usage)

Results (primary 1.7%, secondary 8.4%)

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

	mean	range	count
Regressions ❌ (primary)	1.7%	[1.0%, 2.8%]	6
Regressions ❌ (secondary)	11.3%	[2.1%, 25.8%]	8
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-14.7%	[-14.7%, -14.7%]	1
All ❌✅ (primary)	1.7%	[1.0%, 2.8%]	6

Cycles

Results (primary 2.3%, secondary 22.5%)

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

	mean	range	count
Regressions ❌ (primary)	2.3%	[2.3%, 2.3%]	1
Regressions ❌ (secondary)	25.0%	[2.4%, 43.8%]	10
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.4%	[-2.4%, -2.4%]	1
All ❌✅ (primary)	2.3%	[2.3%, 2.3%]	1

Binary size

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

Bootstrap: 513.812s -> 509.975s (-0.75%)
Artifact size: 398.43 MiB -> 400.31 MiB (0.47%)

ShoyuVanilla · 2026-05-28T15:44:20Z

If my observation is correct, this would fix the perf regression 🤔
@bors try @rust-timer queue

`-Znext-solver` Less normalizes-to janks

rust-bors · 2026-06-09T20:31:00Z

☀️ Try build successful (CI)
Build commit: 4d1f2a6 (4d1f2a670491cb7f00859ca676d850b5e49c41cb, parent: beae781308e9ddef13074a03faf57ca2fac59a5b)

rust-timer · 2026-06-09T21:11:54Z

Finished benchmarking commit (4d1f2a6): 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
@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.4%	[0.2%, 0.8%]	8
Improvements ✅ (primary)	-0.2%	[-0.5%, -0.1%]	26
Improvements ✅ (secondary)	-1.0%	[-5.6%, -0.1%]	47
All ❌✅ (primary)	-0.2%	[-0.5%, -0.1%]	26

Max RSS (memory usage)

Results (secondary -1.9%)

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.4%	[0.8%, 5.5%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.8%	[-16.9%, -0.4%]	7
All ❌✅ (primary)	-	-	0

Cycles

Results (secondary -4.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)	-4.4%	[-5.5%, -2.9%]	8
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 523.273s -> 517.628s (-1.08%)
Artifact size: 400.81 MiB -> 400.74 MiB (-0.02%)

lcnr

good stuff :>

View changes since this review

lcnr · 2026-06-10T09:23:13Z

    /// Because of this we return any ambiguous nested goals from `NormalizesTo` to the
-    /// caller when then adds these to its own context. The caller is always an `AliasRelate`
+    /// caller when then adds these to its own context. The caller is always an `Projection`
    /// goal so this never leaks out of the solver.


can you more completely rewrite this comment and also state that NormalizesTo is just an implementation detail of Projection for associated terms

I feel like NormalizesTois just somewhat of a bad name xx

It should be something like
ProjectionComputeAssocTermCandidate or NormalizeAssocTermInternal or whatever :>

Sure. Would you like to change both this variant and the NormalizesTo goal's names into one of those more proper ones?

I just changed the name of CurrentGoalKind::NormalizesTo for now and left PredicateKind::NormalizesTo as a FIXME for now 😅

lcnr · 2026-06-10T09:26:13Z

                    self.normalization_goal_source,
-                    Goal::new(self.cx(), self.param_env, normalizes_to),
+                    Goal::new(self.cx(), self.param_env, projection),
+                    false,


hmm, I guess it's fine for now. Can you add a FIXME that this whole folder should be removed in favor of proper normalization, cc #156742

lcnr · 2026-06-10T09:28:41Z

+                    normalizes_to,
+                    None,
+                    IncreaseDepthForNested::No,
+                )?;


comments please :3

why do we use a separate goal only for associated terms

why do we not increase the depth for nested goals

edge case that we don't reevaluate the NormalizesTo if equating the unconstrained_term afterwards reesults in inference constraints in the impl headerl, and how that should be fine as we will reevaluate the outer Projectiongoal in that case

I added comments but I'm not totally sure my understandings on those questions are correct 😅

lcnr · 2026-06-11T09:42:34Z

+                // In the new solver, nested goals are evaluated eagerly and the ambiguous nested
+                // goals aren't propagated back to the caller but discarded.
+                //
+                // This behavior made some unfortunate regressions when proving some associated
+                // projection goal, as we may lose the nested goals from the impl candidate's
+                // header which were preserved in the old solver. (See #122687)
+                //
+                // To avoid this, we create a `NormalizesTo` whose expected term is fully
+                // unconstrained and evaluate it as if we are calling a function rather than
+                // evaluating a nested goal, and register its ambiguous nested goals to the
+                // caller's context instead of discarding them.
+                //
+                // This may feel incorrect as we don't reevaluate the ambiguous `NormalizesTo` goal
+                // like other ordinary nested goals. Will we be in trouble if equating
+                // `unconstrained_term` with the expected term results in inference constraints in
+                // the impl header, which should be result in `Certainty::Yes` if we reevaluate it?
+                // Hopefully not, because we apply the certainty of nested `NormalizesTo` goal as
+                // the shallow certainty of the outer associated projection goal. If `NormalizesTo`
+                // returns ambiguity, the caller will do so as well and it and its `NormalizesTo`
+                // will be evaluated again by the caller's outer context.


I think this explanation is not as clear as it could be.

The chain of reasoning here is as follows:

we don't want candidate selection when normalizing associated terms to be impacted by the expected term. normalization should behave like a function of just the alias being normalized

because of this, we use an internal NormalizesTo goal for which the expected term is always fully unconstrained and then equate that to the actual expected term afterwards

this results in weaker type inference if there's a nested where-clause when normalizing which we can actually make progress on based on the expected term. That's what NormalizesTo: return nested goals to caller #122687 is for

And then (imo slightly separately) we don't reevaluate the NormalizesTo goal here even though equating the expected term with the normalization result could add inference constraints to the alias term. This is fine as these inference constraints should cause the caller to reevaluate the current Projection goal, which will then also reevaluate the NormalizesTo goal

View changes since the review

can you move all of this into a normalize_associated_term function or whatever?

lcnr · 2026-06-11T09:43:39Z

@@ -39,19 +34,12 @@ where
            ty::AliasTermKind::ProjectionTy { .. } | ty::AliasTermKind::ProjectionConst { .. } => {
                self.normalize_associated_term(goal)


and here you can keep this match as a debug_assert and just inline normalize_associated_term below it :3

View changes since the review

lcnr

a few more nits, r=me on this impl itself

View changes since this review

We had never stepped into recursive replacement with `AliasRelate` goals when replacing aliases because `AliasRelate` goals don't allow normalization

rustbot · 2026-06-11T16:15:12Z

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.

ShoyuVanilla · 2026-06-11T17:38:02Z

@bors r=lcnr

rust-bors · 2026-06-11T17:38:05Z

📌 Commit 54875bf has been approved by lcnr

It is now in the queue for this repository.

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 May 15, 2026

rustbot assigned lcnr May 15, 2026

ShoyuVanilla mentioned this pull request May 15, 2026

-Znext-solver Remove special handling of NormalizesTo goal #154433

Closed