Add rigid alias marker

[adwinwhite]

View all comments

This PR adds a rigidness marker to TyKind::Alias and ConstKind::Unevaluated. It's used to skip renormalization of rigid aliases. The tracking issue for this is #155345.

The difficulty is that rigid aliases are only valid in their own TypingEnv so we need to force them back to non-rigid when entering another TypingEnv, either because a change to the ParamEnv or because we enter another TypingMode.

Changes to the ParamEnv currently only happen by moving into a new context. We now make sure that EarlyBinder new contains any rigid aliases, this way we have to normalize all aliases contained in it after instantiating.

Changes to the TypingMode are rare, and have to be manually handled.

---

The main changes in this PR are as follows:

• we add enum IsRigid { Yes, No } as a field to TyKind::Alias and ConstKind::Unevaluated. It is always No with the old solver, this makes some of the code less nice than it will be with the old solver removed.
• if we keep an alias as rigid when proving Projection goals we equate the expected term with that alias with IsRigid::Yes
• EarlyBinder::bind now takes the tcx and eagerly sets all IsRigid to No, this is necessary as moving aliases into a different TypingEnv may cause them to no longer be rigid
• EarlyBinder::bind_iter asserts that there are no rigid aliases instead of replacing them
• type relations and generalization always structurally recurse into rigid aliases
• a lot of places in the new solver can ICE when matching on TyKind::Alias with IsRigid::No

---

There's a lot of future work here:

• coherence don't actually rely on lazy norm :<
• remove eq_structurally_relating_aliases, have a special type folder for canonical responses
• yeet AliasRelate, lazily replace non-rigid aliases with infer var + projection goal
• ParamEnv normalization hack to incorrectly mark things as rigid
• eagerly normalize when adding stuff to the fulfillment ctxt :>
• change TypeOutlives goal handling to only expect rigid aliases
• properly expect IsRigid::Yesin region handling (or yes_if_next_solver)
• probably change EarlyBinder::bind to also assert that there are no rigid aliases and manually replacing rigid aliases before then where necessary

---

This PR also adds a flag -Zrenormalize-rigid-aliases to test whether we properly handle typing mode change.

Currently only tests/ui/traits/next-solver/assembly/ambiguity-due-to-uniquification-4.rs fails this check.

r? lcnr

[adwinwhite]

Unfinished. Let's have a look at the perf impact nonetheless.

@bors try @rust-timer queue

[rust-bors]

💔 Test for 73eccb5 failed: CI. Failed job:

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

[adwinwhite]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 42e2939 (42e2939c892f3c5e872d5751bb653ed74736a040, parent: 4b9792692fbb675174d4d2082e7c37b2bc930e71)

[rust-timer]

Finished benchmarking commit (42e2939): comparison URL.

Overall result: ❌ regressions - 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%, 2.2%]	15
Regressions ❌ (secondary)	11.3%	[0.1%, 95.1%]	29
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.1%]	2
All ❌✅ (primary)	0.8%	[0.2%, 2.2%]	15

Max RSS (memory usage)

Results (primary 1.6%, secondary -1.7%)

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

	mean	range	count
Regressions ❌ (primary)	2.1%	[1.7%, 2.7%]	7
Regressions ❌ (secondary)	2.4%	[0.8%, 3.6%]	6
Improvements ✅ (primary)	-2.4%	[-2.4%, -2.4%]	1
Improvements ✅ (secondary)	-4.1%	[-13.8%, -1.1%]	10
All ❌✅ (primary)	1.6%	[-2.4%, 2.7%]	8

Cycles

Results (primary 2.5%, secondary 17.8%)

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

	mean	range	count
Regressions ❌ (primary)	2.5%	[2.4%, 2.6%]	2
Regressions ❌ (secondary)	19.3%	[3.5%, 91.9%]	15
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.7%	[-4.7%, -4.7%]	1
All ❌✅ (primary)	2.5%	[2.4%, 2.6%]	2

Binary size

Results (primary 0.0%, secondary 0.1%)

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

	mean	range	count
Regressions ❌ (primary)	0.0%	[0.0%, 0.0%]	28
Regressions ❌ (secondary)	0.1%	[0.0%, 0.4%]	27
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.0%	[0.0%, 0.0%]	28

Bootstrap: 510.83s -> 514.725s (0.76%)
Artifact size: 400.58 MiB -> 401.07 MiB (0.12%)

[adwinwhite]

@bors try @rust-timer queue

[rust-bors]

💔 Test for 47c3197 failed: CI. Failed job:

• auto - x86_64-gnu-distcheck (web logs, enhanced plaintext logs)

[JonathanBrouwer]

@bors retry
Github is having a time

[rust-log-analyzer]

A job failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

  IMAGE: dist-s390x-linux
##[endgroup]
    Updating crates.io index
error: failed to get `adler2` as a dependency of package `miniz_oxide v0.8.8`
    ... which satisfies dependency `miniz_oxide = "^0.8.5"` of package `flate2 v1.1.9`
    ... which satisfies dependency `flate2 = "^1.1.9"` of package `citool v0.1.0 (/home/runner/work/rust/rust/src/ci/citool)`

Caused by:
  failed to load source for dependency `adler2`

Caused by:
  unable to update registry `crates-io`

Caused by:
  download of ad/le/adler2 failed

Caused by:
  curl failed

Caused by:

[rust-bors]

💔 Test for c18f80f failed: CI. Failed job:

• auto - dist-aarch64-llvm-mingw (web logs, enhanced plaintext logs)

[JonathanBrouwer]

@bors retry

[rust-bors]

☀️ Test successful - CI
Approved by: lcnr
Duration: 3h 18m 56s
Pushing fa36a47 to main...

[github-actions]

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 973ad0d (parent) -> fa36a47 (this PR)

Test differences

Show 108 test diffs

Stage 1

• [ui (polonius)] tests/ui/assumptions_on_binders/non_lifetime_binder_alias_outlives.rs: pass -> [missing] (J0)
• [ui (polonius)] tests/ui/type-alias-impl-trait/const_eval_reveal_opaque_in_param_env.rs: [missing] -> pass (J0)
• [ui] tests/ui/assumptions_on_binders/non_lifetime_binder_alias_outlives.rs: pass -> [missing] (J1)
• [ui] tests/ui/type-alias-impl-trait/const_eval_reveal_opaque_in_param_env.rs: [missing] -> pass (J1)

Stage 2

• [ui] tests/ui/assumptions_on_binders/non_lifetime_binder_alias_outlives.rs: pass -> [missing] (J2)
• [ui] tests/ui/type-alias-impl-trait/const_eval_reveal_opaque_in_param_env.rs: [missing] -> pass (J2)

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

Job group index

• J0: x86_64-gnu-next-trait-solver-polonius
• J1: x86_64-gnu-llvm-21-3, x86_64-gnu-llvm-22-3, x86_64-gnu-next-trait-solver-polonius
• J2: aarch64-apple, aarch64-apple-macos-26, aarch64-gnu, aarch64-gnu-llvm-21-1, aarch64-msvc-1, arm-android, armhf-gnu, dist-i586-gnu-i586-i686-musl, i686-gnu-1, i686-gnu-nopt-1, i686-msvc-1, optional-x86_64-gnu-parallel-frontend, test-various, x86_64-gnu, x86_64-gnu-debug, x86_64-gnu-gcc, x86_64-gnu-llvm-21, x86_64-gnu-llvm-21-2, x86_64-gnu-llvm-22-2, x86_64-gnu-nopt, x86_64-gnu-stable, x86_64-mingw-1, x86_64-msvc-1

Test dashboard

Run

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

1. dist-x86_64-illumos: 1h 10m -> 1h 51m (+58.2%)
2. x86_64-gnu-gcc-core-tests: 12m 31s -> 7m 52s (-37.1%)
3. dist-powerpc64-linux-gnu: 1h 35m -> 1h 5m (-31.1%)
4. x86_64-gnu-llvm-22-1: 1h 13m -> 54m 2s (-26.1%)
5. x86_64-gnu-debug: 2h -> 1h 29m (-25.9%)
6. dist-ohos-x86_64: 1h 2m -> 1h 17m (+24.3%)
7. x86_64-msvc-ext1: 2h 3m -> 1h 37m (-21.1%)
8. x86_64-gnu-gcc: 56m 13s -> 1h 6m (+18.9%)
9. test-various: 2h 10m -> 1h 46m (-18.0%)
10. x86_64-rust-for-linux: 52m 37s -> 43m 28s (-17.4%)

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]

Finished benchmarking commit (fa36a47): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

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)	1.0%	[0.3%, 2.1%]	22
Regressions ❌ (secondary)	1.2%	[0.3%, 3.6%]	13
Improvements ✅ (primary)	-0.1%	[-0.1%, -0.1%]	3
Improvements ✅ (secondary)	-6.0%	[-30.9%, -0.1%]	31
All ❌✅ (primary)	0.8%	[-0.1%, 2.1%]	25

Max RSS (memory usage)

Results (primary 1.9%, secondary -1.4%)

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

	mean	range	count
Regressions ❌ (primary)	1.9%	[1.2%, 3.5%]	8
Regressions ❌ (secondary)	4.4%	[2.5%, 6.5%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.3%	[-16.0%, -0.8%]	12
All ❌✅ (primary)	1.9%	[1.2%, 3.5%]	8

Cycles

Results (primary 2.3%, secondary -2.4%)

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

	mean	range	count
Regressions ❌ (primary)	2.3%	[1.6%, 3.3%]	3
Regressions ❌ (secondary)	5.6%	[2.2%, 13.1%]	16
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-9.8%	[-29.3%, -2.1%]	17
All ❌✅ (primary)	2.3%	[1.6%, 3.3%]	3

Binary size

Results (primary 0.0%, secondary 0.0%)

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

	mean	range	count
Regressions ❌ (primary)	0.0%	[0.0%, 0.0%]	24
Regressions ❌ (secondary)	0.1%	[0.0%, 0.4%]	26
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.0%]	8
All ❌✅ (primary)	0.0%	[0.0%, 0.0%]	24

Bootstrap: 509.16s -> 506.998s (-0.42%)
Artifact size: 353.81 MiB -> 355.28 MiB (0.41%)

[lcnr]

necessary refactor for the new trait solver and I would just eat the 1.4% diesel regression. THe next solver regressions don't matter