Eagerly normalize in generalize by jdonszelmann · Pull Request #151746 · rust-lang/rust

jdonszelmann · 2026-01-27T15:32:19Z

View all comments

r? @lcnr

cc: rust-lang/trait-system-refactor-initiative#262

lcnr · 2026-01-29T18:18:06Z

@bors try @rust-timer queue

… r=<try> Eagerly normalize in generalize

rust-bors · 2026-01-29T18:56:57Z

💔 Test for 92bb985 failed: CI. Failed job:

try - dist-x86_64-linux (web logs, enhanced plaintext logs)

lcnr · 2026-01-30T10:12:19Z

collector error: Failed to profile 'serde-1.0.219-new-solver' with Eprintln, recorded: expected success, got exit status: 101

fun, we've got some jank in serde which we don't have in our ui test suite

compiler/rustc_trait_selection/src/solve.rs

rustbot · 2026-02-05T10:48:02Z

changes to the core type system

cc @lcnr

jdonszelmann · 2026-02-05T10:48:32Z

@lcnr I think this fixes all issues we had. Only one test really regressed, some got a bunch better. Fixed the span on the one test we discussed.

jdonszelmann · 2026-02-05T14:06:19Z

@GuillaumeGomez is this another flaky test?

rustbot · 2026-02-26T13:57:25Z

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.

compiler/rustc_infer/src/infer/relate/generalize.rs

lcnr · 2026-02-26T17:57:50Z

compiler/rustc_trait_selection/src/solve.rs

+    span: Span,
+    alias: ty::AliasTy<'tcx>,
+) -> Ty<'tcx> {
+    let infcx = unsafe {


do you want to encapsulate these transmute in inhernet functions on InferCtxt and add a safety comment there?

lcnr · 2026-02-26T18:02:53Z

tests/ui/impl-trait/unsized_coercion.rs

@@ -12,7 +13,6 @@ impl Trait for u32 {}
 fn hello() -> Box<impl Trait> {
    if true {
        let x = hello();
-        //[next]~^ ERROR: the size for values of type `dyn Trait` cannot be known at compilation time
        let y: Box<dyn Trait> = x;
    }


hmm, I don't fully get that 🤔

What does "implicitly contains the + Sized bound" mean? For coerce to consider that Sized bound, it has to be in the root fulfillment context I think?

How does that Sized bound get there. I am also surprised that x has to be equal to the return type of hello() instead of a subtype, how does that happen? ✨

lcnr

reflowing the comments :<

r=me after this nit

View changes since this review

lcnr · 2026-03-19T10:32:28Z

compiler/rustc_infer/src/infer/relate/generalize.rs

+    /// Treat aliases as potentially normalizable.
+    ///
+    /// This is the default state that generalization starts in, unless we're treating aliases as rigid.
+    /// It also means we're not currently inside an alias, since then we change the state to
+    /// `IncompletelyRelateAliasArgs`
+    Default,
+    /// We enter this state when we're generalizing the arguments of a potentially normalizeable alias.
+    ///
+    /// The behavior here is different between the old and the new solver:
+    ///
+    /// In the old solver, the difference between this and `Default` is needed to
+    /// correctly handle `<T as Bar<<?0 as Foo>::Assoc>::Assoc == ?0`.
+    /// That equality can hold by either normalizing the outer or the inner associated type.
+    /// In the old solver, we always structurally relate aliases,
+    /// however, when we encounter an occurs check failure, we propagate the failure to the outermost alias,
+    /// for which we then emit a Projection goal.
+    ///
+    /// In the new solver, we rarely get into this state.
+    /// When we encounter aliases we instead attempt to normalize them, and treat them as rigid using `ShallowStructurallyRelate`.
+    /// Only when an alias is higher-ranked, we continue with similar logic to the old solver,
+    /// except now we also explicitly relate the type and consts in the arguments of aliases while in this mode.
+    ///
+    /// FIXME: Because we relate the type and consts in the arguments of aliases while in this mode,
+    ///        this is "incomplete".
+    IncompletelyRelateAliasArgs,
+    /// During generalization, when we encounter aliases,
+    /// we will first attempt to normalize them when we're using the next trait solver.
+    /// We can now treat the normalized alias as rigid, but only for "one layer", hence shallow.
+    /// New aliases encountered inside the arguments of the outer alias should once again be related as normal.
+    ShallowStructurallyRelateAliases,
+    /// Treat aliases as rigid when relating them.
+    ///
+    /// This corresponds to `relation.structurally_relate_aliases()`.
+    StructurallyRelateAliases,


Suggested change

/// Treat aliases as potentially normalizable.

///

/// This is the default state that generalization starts in, unless we're treating aliases as rigid.

/// It also means we're not currently inside an alias, since then we change the state to

/// `IncompletelyRelateAliasArgs`

Default,

/// We enter this state when we're generalizing the arguments of a potentially normalizeable alias.

///

/// The behavior here is different between the old and the new solver:

///

/// In the old solver, the difference between this and `Default` is needed to

/// correctly handle `<T as Bar<<?0 as Foo>::Assoc>::Assoc == ?0`.

/// That equality can hold by either normalizing the outer or the inner associated type.

/// In the old solver, we always structurally relate aliases,

/// however, when we encounter an occurs check failure, we propagate the failure to the outermost alias,

/// for which we then emit a Projection goal.

///

/// In the new solver, we rarely get into this state.

/// When we encounter aliases we instead attempt to normalize them, and treat them as rigid using `ShallowStructurallyRelate`.

/// Only when an alias is higher-ranked, we continue with similar logic to the old solver,

/// except now we also explicitly relate the type and consts in the arguments of aliases while in this mode.

///

/// FIXME: Because we relate the type and consts in the arguments of aliases while in this mode,

/// this is "incomplete".

IncompletelyRelateAliasArgs,

/// During generalization, when we encounter aliases,

/// we will first attempt to normalize them when we're using the next trait solver.

/// We can now treat the normalized alias as rigid, but only for "one layer", hence shallow.

/// New aliases encountered inside the arguments of the outer alias should once again be related as normal.

ShallowStructurallyRelateAliases,

/// Treat aliases as rigid when relating them.

///

/// This corresponds to `relation.structurally_relate_aliases()`.

StructurallyRelateAliases,

/// Treat aliases as potentially normalizable.

///

/// This is the default state that generalization starts in, unless we're

/// treating aliases as rigid. It also means we're not currently inside an

/// alias, since then we change the state to `IncompletelyRelateAliasArgs`.

Default,

/// We enter this state when we're generalizing the arguments of a

/// potentially normalizeable alias.

///

/// The behavior here is different between the old and the new solver:

///

/// In the old solver, the difference between this and `Default` is needed to

/// correctly handle `<T as Bar<<?0 as Foo>::Assoc>::Assoc == ?0`. That

/// equality can hold by either normalizing the outer or the inner

/// associated type. In the old solver, we always structurally relate

/// aliases. If we we encounter an occurs check failure, we propagate the

/// failure to the outermost alias, for which we then emit a `Projection`

/// goal instead.

///

/// In the new solver, we rarely get into this state.

/// When we encounter aliases we instead attempt to normalize them, and treat

/// them as rigid using `ShallowStructurallyRelate`. Only when an alias has

/// escaping bound variables do we continue with similar logic to the old

/// solver, except now we also explicitly relate the type and consts in the

/// arguments of aliases while in this mode.

///

/// FIXME: Because we relate the type and consts in the arguments of aliases

/// while in this mode, this is incomplete.

IncompletelyRelateAliasArgs,

/// During generalization, when we encounter aliases, we will first attempt

/// to normalize them when we're using the next trait solver. We can now

/// treat the normalized alias as rigid, but only for "one layer", hence

/// shallow. New aliases encountered inside the arguments of the outer alias

/// should once again be related as normal.

ShallowStructurallyRelateAliases,

/// Treat aliases as rigid when relating them.

///

/// This corresponds to `relation.structurally_relate_aliases()`.

StructurallyRelateAliases,

jdonszelmann · 2026-03-20T13:03:05Z

@bors r=lcnr

rust-bors · 2026-03-20T13:03:09Z

📌 Commit d665c0b has been approved by lcnr

It is now in the queue for this repository.

rust-bors · 2026-03-20T21:31:26Z

☀️ Test successful - CI
Approved by: lcnr
Duration: 3h 8m 32s
Pushing ac7f9ec to main...

github-actions · 2026-03-20T21:34:16Z

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 bfc05d6 (parent) -> ac7f9ec (this PR)

Test differences

Show 8 test diffs

Stage 1

[ui] tests/ui/traits/next-solver/generalize/eagely-normalizing-aliases.rs#next: [missing] -> pass (J1)
[ui] tests/ui/traits/next-solver/generalize/eagely-normalizing-aliases.rs#old: [missing] -> pass (J1)

Stage 2

[ui] tests/ui/traits/next-solver/generalize/eagely-normalizing-aliases.rs#next: [missing] -> pass (J0)
[ui] tests/ui/traits/next-solver/generalize/eagely-normalizing-aliases.rs#old: [missing] -> pass (J0)

Additionally, 4 doctest diffs were found. These are ignored, as they are noisy.

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard ac7f9ec7da74d37fd28667c86bf117a39ba5b02a --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

dist-aarch64-llvm-mingw: 1h 51m -> 1h 28m (-20.3%)
x86_64-gnu: 2h 10m -> 2h 25m (+11.9%)
test-various: 1h 55m -> 2h 8m (+11.8%)
x86_64-gnu-llvm-22-3: 1h 45m -> 1h 55m (+9.0%)
optional-x86_64-gnu-parallel-frontend: 2h 29m -> 2h 42m (+8.8%)
x86_64-gnu-llvm-21-3: 1h 57m -> 2h 7m (+8.4%)
dist-x86_64-musl: 2h 19m -> 2h 7m (-8.2%)
arm-android: 1h 47m -> 1h 39m (-8.2%)
dist-powerpc64-linux-musl: 1h 40m -> 1h 32m (-7.8%)
dist-x86_64-llvm-mingw: 1h 56m -> 1h 47m (-7.8%)

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-03-20T22:12:46Z

Finished benchmarking commit (ac7f9ec): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

If the regression was expected or you think it can be justified,
please write a comment with sufficient written justification, and add
@rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
If you think that you know of a way to resolve the regression, try to create
a new PR with a fix for the regression.
If you do not understand the regression or you think that it is just noise,
you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

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.2%	[0.2%, 0.3%]	7
Regressions ❌ (secondary)	0.3%	[0.1%, 0.4%]	10
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.4%	[-0.4%, -0.4%]	1
All ❌✅ (primary)	0.2%	[0.2%, 0.3%]	7

Max RSS (memory usage)

Results (primary 0.7%, secondary -0.6%)

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)	1.1%	[1.1%, 1.1%]	1
Improvements ✅ (primary)	-0.9%	[-0.9%, -0.9%]	1
Improvements ✅ (secondary)	-1.5%	[-1.7%, -1.2%]	2
All ❌✅ (primary)	0.7%	[-0.9%, 2.3%]	2

Cycles

Results (secondary -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
Regressions ❌ (secondary)	2.2%	[2.2%, 2.2%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.8%	[-3.6%, -2.1%]	2
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 485.797s -> 485.09s (-0.15%)
Artifact size: 396.97 MiB -> 394.98 MiB (-0.50%)

matthiaskrgr · 2026-03-21T12:43:13Z

compiler/rustc_infer/src/infer/relate/generalize.rs

this unwrap-errs here: #154173

rustbot assigned lcnr Jan 27, 2026

This comment has been minimized.

Sign in to view

rust-bors bot pushed a commit that referenced this pull request Jan 29, 2026

Auto merge of #151746 - jdonszelmann:eagerly-normalize-in-generalize,…

92bb985

… r=<try> Eagerly normalize in generalize

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

This comment has been minimized.

Sign in to view

jdonszelmann force-pushed the eagerly-normalize-in-generalize branch from 5bd20bb to d0cdaae Compare February 2, 2026 18:38

This comment has been minimized.

Sign in to view

jdonszelmann force-pushed the eagerly-normalize-in-generalize branch from d0cdaae to fb5d5cf Compare February 3, 2026 15:04

This comment has been minimized.

Sign in to view

jdonszelmann force-pushed the eagerly-normalize-in-generalize branch from fb5d5cf to d96cab0 Compare February 3, 2026 15:51

This comment has been minimized.

Sign in to view

lcnr reviewed Feb 4, 2026

View reviewed changes

compiler/rustc_trait_selection/src/solve.rs Outdated Show resolved Hide resolved

jdonszelmann force-pushed the eagerly-normalize-in-generalize branch from d96cab0 to 5611a89 Compare February 5, 2026 10:47

jdonszelmann marked this pull request as ready for review February 5, 2026 10:47

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 Feb 5, 2026

jdonszelmann force-pushed the eagerly-normalize-in-generalize branch from 5611a89 to 3f90d08 Compare February 5, 2026 10:50

This comment has been minimized.

Sign in to view

lcnr and others added 6 commits February 26, 2026 14:53

explicitly provide type in transmute

7a123e8

normalize at the start of generalize if we can

f50591f

try generalizing if normalization isn't a tyvar

e8e3544

fixup span in obligation cause

2d411a0

bless some tests

6edf58f

inline into

9aa065b

jdonszelmann force-pushed the eagerly-normalize-in-generalize branch from 29ae136 to 1adea68 Compare February 26, 2026 13:57

lcnr reviewed Feb 26, 2026

View reviewed changes

jdonszelmann force-pushed the eagerly-normalize-in-generalize branch from 1adea68 to 60e068f Compare March 19, 2026 09:48

lcnr reviewed Mar 19, 2026

View reviewed changes

address review

d665c0b

jdonszelmann force-pushed the eagerly-normalize-in-generalize branch from 60e068f to d665c0b Compare March 20, 2026 13:02

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

This comment has been minimized.

Sign in to view

rust-bors bot added merged-by-bors This PR was explicitly merged by bors. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 20, 2026

rust-bors bot merged commit ac7f9ec into rust-lang:main Mar 20, 2026
12 checks passed

rustbot added this to the 1.96.0 milestone Mar 20, 2026

This was referenced Mar 20, 2026

Chore/move more types to ir #152706

Draft

Properly generalize unevaluated consts #154053

Open

matthiaskrgr mentioned this pull request Mar 21, 2026

[ICE]: called Result::unwrap_err() on an Ok value: W<'?2, {type error}> #154173

Open

matthiaskrgr reviewed Mar 21, 2026

View reviewed changes

compiler/rustc_infer/src/infer/relate/generalize.rs

Copy link

Member

matthiaskrgr Mar 21, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this unwrap-errs here: #154173

matthiaskrgr mentioned this pull request Mar 21, 2026

[ICE]: equating two type variables, both of which have known types #154189

Open

Uh oh!

Conversation

jdonszelmann commented Jan 27, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

lcnr commented Jan 29, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

rust-bors bot commented Jan 29, 2026

Uh oh!

lcnr commented Jan 30, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

Uh oh!

rustbot commented Feb 5, 2026

Uh oh!

jdonszelmann commented Feb 5, 2026

Uh oh!

This comment has been minimized.

jdonszelmann commented Feb 5, 2026

Uh oh!

rustbot commented Feb 26, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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!

jdonszelmann commented Mar 20, 2026

Uh oh!

rust-bors bot commented Mar 20, 2026

Uh oh!

This comment has been minimized.

rust-bors bot commented Mar 20, 2026

Uh oh!

Uh oh!

github-actions bot commented Mar 20, 2026

Test differences

Stage 1

Stage 2

Job duration changes

Uh oh!

rust-timer commented Mar 20, 2026

Overall result: ❌✅ regressions and improvements - please read the text below

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

jdonszelmann commented Jan 27, 2026 •

edited by rustbot

Loading

lcnr left a comment •

edited by rustbot

Loading