[Experiment] Add rigid alias marker by adwinwhite · Pull Request #156742 · rust-lang/rust

adwinwhite · 2026-05-19T09:48:47Z

View all comments

still WIP but push before leaving the computer.

r? lcnr

adwinwhite · 2026-05-19T09:52:11Z

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

@bors try @rust-timer queue

[Experiment] Add rigid alias marker

rust-bors · 2026-05-19T11:47:51Z

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

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

adwinwhite · 2026-05-20T03:06:55Z

@bors try @rust-timer queue

[Experiment] Add rigid alias marker

rust-bors · 2026-05-20T05:15:45Z

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

rust-timer · 2026-05-20T05:57:06Z

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 · 2026-05-20T07:42:00Z

@bors try @rust-timer queue

[Experiment] Add rigid alias marker

rust-bors · 2026-05-22T09:42:11Z

☀️ Try build successful (CI)
Build commit: 9ad2ace (9ad2ace8afa254bb715d50d44f15a8409f31c60a, parent: 3bf5c6d99bc8a0c0d5b2f69826ed4f6d256a0a21)

rust-timer · 2026-05-22T10:23:42Z

Finished benchmarking commit (9ad2ace): 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.7%	[0.1%, 3.2%]	41
Regressions ❌ (secondary)	0.8%	[0.0%, 6.4%]	53
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-7.6%	[-19.7%, -0.3%]	16
All ❌✅ (primary)	0.7%	[0.1%, 3.2%]	41

Max RSS (memory usage)

Results (primary 2.2%, secondary -4.3%)

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

	mean	range	count
Regressions ❌ (primary)	2.2%	[1.5%, 2.5%]	5
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.3%	[-16.6%, -0.9%]	11
All ❌✅ (primary)	2.2%	[1.5%, 2.5%]	5

Cycles

Results (primary 2.6%, secondary -4.1%)

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

	mean	range	count
Regressions ❌ (primary)	2.6%	[2.2%, 2.8%]	5
Regressions ❌ (secondary)	3.8%	[2.5%, 4.6%]	8
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-9.3%	[-19.7%, -5.6%]	12
All ❌✅ (primary)	2.6%	[2.2%, 2.8%]	5

Binary size

Results (primary 0.1%, 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.1%	[0.0%, 0.1%]	98
Regressions ❌ (secondary)	0.1%	[0.0%, 0.4%]	62
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.1%	[0.0%, 0.1%]	98

Bootstrap: 513.065s -> 515.25s (0.43%)
Artifact size: 400.58 MiB -> 401.26 MiB (0.17%)

adwinwhite · 2026-05-26T09:49:05Z

@bors try @rust-timer queue

[Experiment] Add rigid alias marker

rust-bors · 2026-05-26T12:04:54Z

☀️ Try build successful (CI)
Build commit: 65383a4 (65383a4093049a4ac0e44cd9843df9bdc9a19acc, parent: b7e97a98f24cdb1335850209991455cb9734d333)

lcnr

I am slightly unhappy about the way you currently handle instantiate_identity 🤔

The easiest solution for now would be for EarlyBinder::new to replace all rigid aliases with non rigid ones 🤔 while that does cause us to sometimes renormalize aliases even though that shouldn't be necessary, I expect that to be rather rare and wouldn't worry about that unless for now?

View changes since this review

lcnr · 2026-05-26T11:44:24Z

-    INSTANTIATE_RHS_WITH_INFER,
->;
+pub type DeepRejectCtxt<'tcx, const HANDLE_LHS: u8, const HANDLE_RHS: u8> =
+    rustc_type_ir::fast_reject::DeepRejectCtxt<TyCtxt<'tcx>, HANDLE_LHS, HANDLE_RHS>;


surprising change 🤔 I feel like this should be unnecessary if we now use rigid aliases instead

This is from your commit? Or u clicked the wrong lines?

lcnr · 2026-05-26T11:51:41Z

+            && alias.is_rigid == ty::IsRigid::Yes
+            && !(ty.has_opaque_types()
+                && matches!(self.infcx.typing_mode_raw(), TypingMode::PostAnalysis))


so the way you currently handle TypingEnv changes is by never treating affected things as rigid in post analysis?

This is unfortunately insufficient 🤔 imagine having the where-clauses T: Trait<u32> and T: Trait<TaitNotInDefiningScope, Assoc = u32>. With this <T as Trait<u32>>::Assoc is now rigid during analysis, but if we TaitNotInDefiningScope is defined to u32 we can now normalize it to u32 at this point.

I don't know expect this to ever cause problems in practice, do feel like it is quite brittle though and would prefer to not have to even consider that as a theoretical concern

Great example. Never thought that opaques in param env can affect other rigid aliases indirectly.
Items with where-clauses T: Trait<u32> and T: Trait<TaitNotInDefiningScope> are unusable as the coherence check is bound to fail if we have the two required impls.

I don't know how to detect all typing mode changes and be defensive about them 🤔.
It seems the opaque_types && PostAnalysis check is unnecessary if we handle EarlyBinder well.
MIR instantiation will go through EarlyBinder. Another notable typing mode change is layout_of.
I didn't find other places that leak rigid opaques into PostAnalysis, by turning the check into an assert. Though the assert can't detect your example.

lcnr · 2026-05-26T11:53:01Z

+            // FIXME: how to best detect rigid? Follow `compute_alias_relate` for now.
+            // Can we have infer vars in rigid aliases?
+            if let ty::Alias(alias_ty) = normalized_ty.kind() {
+                I::Ty::new_alias(self.cx(), alias_ty.to_rigid())
+            } else {
+                normalized_ty
+            }


I would expect the only place to create rigid aliases to be NormalizesTo. More specifically, all uses of structurally_instantiate_normalizes_to_term

rust/compiler/rustc_next_trait_solver/src/solve/normalizes_to/mod.rs

Lines 108 to 112 in b7e97a9

this.structurally_instantiate_normalizes_to_term(

goal,

goal.predicate.alias,

);

this.evaluate_added_goals_and_make_canonical_response(Certainty::Yes)

lcnr · 2026-05-26T11:56:35Z

+                } else {
+                    None
+                }
+            }


this feels like sth we could/definitely should split out into a separate PR?

It is unfortunately also not correct for AliasRelate as you could have <T as Trait<?normalizing_the_lhs_constrains_this>>::Assoc eq <?normalizing_the_lhs_constrains_this as Whatever>::Assoc`.

I think we rigid aliases we don't need alias relate anymore. When type relations encounter non-rigid aliases, they can replace the alias with an infer var, add a nested Projection goal and then just continue to recur with that infer var instead

lcnr · 2026-05-26T12:02:20Z

+            ty::Alias(alias_ty) if alias_ty.is_rigid == ty::IsRigid::Yes => {
+                let alias_ty = alias_ty.fold_with(self);
+                I::Ty::new_alias(self.cx(), alias_ty.to_non_rigid())
+            }


instantiate also needs to make aliases non-rigid even if tehy don't contain any params. The !t.has_param fast path also needs to check for rigid aliases so that we replace all of them.

Otherwise instantiating some_opaque in a typing env that can define some_opaque incorrectly treats it as rigid

rust-timer · 2026-05-26T12:46:48Z

Finished benchmarking commit (65383a4): 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.1%, 1.2%]	42
Regressions ❌ (secondary)	1.0%	[0.2%, 6.5%]	42
Improvements ✅ (primary)	-0.1%	[-0.1%, -0.1%]	1
Improvements ✅ (secondary)	-7.6%	[-18.8%, -0.3%]	16
All ❌✅ (primary)	0.4%	[-0.1%, 1.2%]	43

Max RSS (memory usage)

Results (primary 2.6%, secondary -4.6%)

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

	mean	range	count
Regressions ❌ (primary)	2.6%	[0.7%, 7.3%]	4
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.6%	[-17.6%, -0.9%]	12
All ❌✅ (primary)	2.6%	[0.7%, 7.3%]	4

Cycles

Results (primary 3.7%, secondary -4.9%)

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

	mean	range	count
Regressions ❌ (primary)	3.7%	[3.7%, 3.7%]	1
Regressions ❌ (secondary)	3.9%	[3.1%, 4.7%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-9.0%	[-18.0%, -2.6%]	13
All ❌✅ (primary)	3.7%	[3.7%, 3.7%]	1

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%]	27
Regressions ❌ (secondary)	0.1%	[0.0%, 0.4%]	21
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.0%	[0.0%, 0.0%]	27

Bootstrap: 511.751s -> 516.392s (0.91%)
Artifact size: 400.67 MiB -> 401.35 MiB (0.17%)

adwinwhite · 2026-05-28T03:30:13Z

I am slightly unhappy about the way you currently handle instantiate_identity 🤔
The easiest solution for now would be for EarlyBinder::new to replace all rigid aliases with non rigid ones 🤔 while that does cause us to sometimes renormalize aliases even though that shouldn't be necessary, I expect that to be rather rare and wouldn't worry about that unless for now?

This is not easy for several reasons:

We don't have tcx when calling EarlyBinder::bind in some places. This can be walked around by changing related method signatures to pass tcxin.
The input might not be TypeFoldable. It may rely on Deref + Copy to instantiate. See iter_instantiated_copied. This may be walked around with new EarlyBinder::bind variants which can have different where bounds. But it makes composing with other EarlyBinder methods harder.
map/rebind method on EarlyBinder also faces the two challenges above. Besides, they share names with methods on Binder which makes it difficult to convert their call sites mechanically.

In the alternative approach where we replace all rigid aliases with non-rigid in instantiate and instantiate_identity, we have the concern that callers of EarlyBinder::skip_binder may access rigid aliases?

rustbot assigned lcnr May 19, 2026