`-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

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.

`-Znext-solver` Less normalizes-to janks cc rust-lang/trait-system-refactor-initiative#223 (comment) r? lcnr

rust-bors · 2026-06-12T03:19:24Z

💔 Test for 812b7d1 failed: CI. Failed job:

auto - dist-loongarch64-linux (web logs, enhanced plaintext logs)

jhpratt · 2026-06-12T03:29:31Z

The tail of that log shows nothing out of the ordinary, not even a spurious failure.

@bors retry

lcnr · 2026-06-12T10:47:35Z

        };

-        self.instantiate_normalizes_to_term(goal, actual);
+        self.push_const_arg_has_type_goal(goal.param_env, goal.predicate.projection_term, actual);


Why are you adding that?

View changes since the review

ah hmm, it's interesting that we add const_arg_has_type here. I guess you're just inlining that function. cc @BoxyUwU why do we do it this way and not more specifically for free consts or sth like that?

Yeah, I'm inlining it. It has been introduced in #154853 to fix some ICEs

lcnr · 2026-06-12T10:48:06Z

+            goal.param_env,
+            goal.predicate.projection_term,
+            normalized,
+        );


same 🤔

View changes since the review

lcnr · 2026-06-12T10:49:46Z

+        self.inspect.make_canonical_response(Certainty::AMBIGUOUS);
+
+        // Apply the constraints.
+        self.try_evaluate_added_goals()?;


we don't add any nested goals here. This only handles the goals from replace_alias_with_infer. Move that below the make_canonical_response maybe?

View changes since the review

Yeah, but my intention here is solving those very goals from replace_alias_with_infer, to normalize the expected term. If we don't do this before structurally equating normalized term and the expected term below, it may fail if the expected term isn't rigid but can be normalized further.

I guess this would be unnecessary due to eager normalization or rigidness marker likewise replacing aliases with infer above but I'm doing it to avoid regressing some tests 😅

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

rustbot · 2026-06-13T03:29:48Z

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.

rust-bors · 2026-06-13T11:45:46Z

☔ The latest upstream changes (presumably #157852) made this pull request unmergeable. Please resolve the merge conflicts.

khyperia · 2026-06-13T13:01:30Z


        let ct = ct.super_fold_with(self);
-        let ty::ConstKind::Unevaluated(..) = ct.kind() else { return ct };
+        let ty::ConstKind::Unevaluated(uc) = ct.kind() else { return ct };


silly nit that's not important to fix for this PR, just for the future - I think we typically call UnevaluatedConst variables uv instead of uc. But, we're renaming UnevaluatedConst to AliasConst soon, so perhaps a moot point.

this PR is super cool though! learned a lot reading through it, especially the comments you added in project_goals/mod.rs, heck yeah

(sorry for the merge conflict due to my AliasTerm::def_id PR that just merged :c )

View changes since the review

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