skip proving the trait goal if possible in `NormalizesTo` goal by adwinwhite · Pull Request #149533 · rust-lang/rust

adwinwhite · 2025-12-02T06:23:56Z

And also split assembly_and_merge_candidates for HostEffect and NormalizesTo goals.

also split the `assembly_and_merge_candidates` for `HostEffect` and `NormalizesTo`

adwinwhite · 2025-12-02T06:25:32Z

compiler/rustc_next_trait_solver/src/solve/effect_goals.rs

Not sure whether candidate preference matters to effect goal.

it's whatever :> please add a FIXME(const_traits) to assemble_and_merge_candidates that this was copied from the old projection normalization behavior and might not be what we actually want here

adwinwhite · 2025-12-02T06:27:56Z

...traits/next-solver/normalization-shadowing/normalizes_to_ignores_unnormalizable_candidate.rs

 //
-// We currently intentionally do not guide inference this way.
+// Since we skip proving the trait goal in normalizes-to goal now, the normalizes-to
+// goal can successfully resolve the infer var via param env.


This seems unavoidable since we don't know whether the trait goal will succeed or not at this time.

lcnr

fun, this isn't quite the behavior of the old trait solver either :3

the old solver only skips trying to prove the trait goal of we've got a builtin trait object impls. I think this ended up not really being necessary after your previous work?

idk... this sucks xd

let's see if the change impacts perf in a major way. If so, we can still avoid assembling impls in some cases at least :3

View changes since this review

lcnr · 2025-12-02T10:48:29Z

compiler/rustc_next_trait_solver/src/solve/normalizes_to/projection.rs

+    D: SolverDelegate<Interner = I>,
+    I: Interner,
+{
+    pub(super) fn normalize_trait_associated_term(


Suggested change

pub(super) fn normalize_trait_associated_term(

pub(super) fn normalize_projection_term(

that's what we use in AliasTermKind 🤔

lcnr · 2025-12-02T10:50:15Z

...traits/next-solver/normalization-shadowing/normalizes_to_ignores_unnormalizable_candidate.rs

-// We currently intentionally do not guide inference this way.
+// Since we skip proving the trait goal in normalizes-to goal now, the normalizes-to
+// goal can successfully resolve the infer var via param env.
+// This causes the stalled ambiguous trait goal to succeed as well.


this also doesn't compile with the old solver right now 🤔 why?

ah, because the old solver always uses assemble_candidates_from_impls and forces ambiguity unless assembly resulted in a builtin trait object candidate :<

that's wild xx

I do think we should not merge this PR with this behavior change 🤔

We should check that the param_env trait candidates are not ambig. You could manually check that they are not, but unsure how to do so without eating a lot of the perf benefit again

lcnr · 2025-12-02T10:50:59Z

compiler/rustc_next_trait_solver/src/solve/effect_goals.rs

+            // We don't care about overflow. If proving the trait goal overflowed, then
+            // it's enough to report an overflow error for that, we don't also have to
+            // overflow during normalization.


Suggested change

// We don't care about overflow. If proving the trait goal overflowed, then

// it's enough to report an overflow error for that, we don't also have to

// overflow during normalization.

// We don't care about overflow. If proving the trait goal overflowed, then

// it's enough to report an overflow error for that, we don't also have to

// overflow for the const bound.

or sth

lcnr · 2025-12-02T10:51:59Z

compiler/rustc_next_trait_solver/src/solve/effect_goals.rs

it's whatever :> please add a FIXME(const_traits) to assemble_and_merge_candidates that this was copied from the old projection normalization behavior and might not be what we actually want here

lcnr · 2025-12-02T10:52:52Z

compiler/rustc_next_trait_solver/src/solve/normalizes_to/projection.rs

+        // If we're normalizing an GAT, we bail if using a where-bound would constrain
+        // its generic arguments.
+        // FIXME(generic_associated_types): Addresses aggressive inference in #92917.


flip these two statements. I want the comment to start with the FIXME. Right now it seems like the first line is separate from the content of the FIXME

lcnr · 2025-12-02T10:58:49Z

compiler/rustc_next_trait_solver/src/solve/normalizes_to/projection.rs

+        &mut self,
+        goal: Goal<I, ty::NormalizesTo<I>>,
+    ) -> QueryResult<I> {
+        let (mut candidates, _) =


comment: something something we already looked for param_env and alias-bound candidates so we don't have to assemble them again

lcnr · 2025-12-02T11:08:12Z

@bors try @rust-timer queue

skip proving the trait goal if possible in `NormalizesTo` goal

rust-bors · 2025-12-02T13:23:47Z

☀️ Try build successful (CI)
Build commit: 405e127 (405e127a5ed88fdce13f91d651e2346944cc27f1, parent: 47cd7120d9b4e1b64eb27c87522a07888197fae8)

rust-timer · 2025-12-02T14:43:41Z

Finished benchmarking commit (405e127): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@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
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-12.9%	[-40.3%, -0.3%]	9
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (secondary 0.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.6%	[2.6%, 2.6%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.9%	[-1.0%, -0.9%]	2
All ❌✅ (primary)	-	-	0

Cycles

Results (secondary -21.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)	-	-	0
Improvements ✅ (secondary)	-21.1%	[-25.0%, -17.0%]	3
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 469.029s -> 471.041s (0.43%)
Artifact size: 386.77 MiB -> 386.75 MiB (-0.00%)

adwinwhite · 2025-12-12T03:30:17Z

compiler/rustc_next_trait_solver/src/solve/normalizes_to/projection.rs

+                    // ambiguous fallback candidate. It happens to be this object assembly call
+                    // here.
+                    let (candidates, _) =
+                        self.assemble_and_evaluate_candidates(goal, AssembleCandidatesFrom::Object);


Moved object candidate out of the fast path to avoid coherence issues.

which coherence issue? what's the difference between EnvAndBounds and EnvAndBoundsFastPath?

ah I see. That structure feels odd and unintuitive 🤔

maybe we should do an even larger refactoring 🤔 make normalize self ty + opaque types jank a sub-fn returning an Option for the "self ty is infer" case, and then use that directly.

Would need to think about the structure more myself, but I do think having a bunch of control flow inside of our functions makes code hard to understand and duplicating (parts of) the behavior may be better here.

rust-bors · 2026-03-31T20:38:41Z

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

skip proving trait goal if possible in NormalizesTo goal

6955473

also split the `assembly_and_merge_candidates` for `HostEffect` and `NormalizesTo`

rustbot assigned lcnr Dec 2, 2025

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 Dec 2, 2025

adwinwhite commented Dec 2, 2025

View reviewed changes

This comment has been minimized.

Sign in to view

adwinwhite marked this pull request as draft December 2, 2025 08:44

rustbot 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-review Status: Awaiting review from the assignee but also interested parties. labels Dec 2, 2025

lcnr reviewed Dec 2, 2025

View reviewed changes

This comment has been minimized.

Sign in to view

rust-bors bot added a commit that referenced this pull request Dec 2, 2025

Auto merge of #149533 - adwinwhite:skip-trait-goal-if-possible, r=<try>

405e127

skip proving the trait goal if possible in `NormalizesTo` goal

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Dec 2, 2025

This comment has been minimized.

Sign in to view

rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Dec 2, 2025

adwinwhite added 2 commits December 12, 2025 11:16

fix coherence and blanket impl tests

bd604d2

apply review suggestions

7e6a2a6

adwinwhite commented Dec 12, 2025

View reviewed changes

adwinwhite marked this pull request as ready for review December 12, 2025 04:59

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Dec 12, 2025

lcnr 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-review Status: Awaiting review from the assignee but also interested parties. labels Dec 20, 2025

	pub(super) fn normalize_trait_associated_term(
	pub(super) fn normalize_projection_term(

Uh oh!

Conversation

adwinwhite commented Dec 2, 2025

Uh oh!

adwinwhite Dec 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

lcnr left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lcnr commented Dec 2, 2025

Uh oh!

This comment has been minimized.

This comment has been minimized.

rust-bors bot commented Dec 2, 2025

Uh oh!

This comment has been minimized.

rust-timer commented Dec 2, 2025

Overall result: ✅ improvements - no action needed

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rust-bors bot commented Mar 31, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

adwinwhite Dec 2, 2025 •

edited

Loading

lcnr left a comment •

edited by rustbot

Loading