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

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

This PR adds a rigidness marker to AliasTy/AliasTerm/UnevaluatedConst.
It's used to skip renormalization of rigid aliases.

The difficulty is that rigid aliases are only valid in their own TypingEnv so we need to treat them as non-rigid when entering another TypingEnv.

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

adwinwhite · 2026-06-10T07:51:29Z

@bors try @rust-timer queue

[Experiment] Add rigid alias marker

rustbot · 2026-06-10T09:46:00Z

Some changes occurred in compiler/rustc_sanitizers

cc @rcvalle

Some changes occurred in rustc_ty_utils::consts.rs

cc @BoxyUwU

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

HIR ty lowering was modified

cc @fmease

clippy is developed in its own repository. If possible, consider making this change to rust-lang/rust-clippy instead.

cc @rust-lang/clippy

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

rustc_codegen_cranelift is developed in its own repository. If possible, consider making this change to rust-lang/rustc_codegen_cranelift instead.

cc @bjorn3

changes to the core type system

cc @lcnr

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

lcnr · 2026-06-10T09:51:01Z

-                                ty,
+                                // FIXME(rigid_aliases_marker): types coming out of `item_bounds`
+                                // are marked as non-rigid while the visited ty can be rigid.
+                                ty::set_aliases_to_non_rigid(tcx, ty),


surprising. If args contain something that's rigid, shouldn't it be fine to keep that as rigid?

View changes since the review

Relating of AliasTy now checks rigidness. And we have relating in test_type_match::extract_verify_if_eq.

Ah this reminds me that if the args contains rigid aliases, setting them to non-rigid would also cause discrepancy with the type instantiated from item bound.

as in, we relate non-rigid with rigid aliases here?

lcnr

I feel like longterm we should have ty::Aliasand ty::RigidAlias as separate variants on both Ty and Const as most code should only ever encounter one of them 🤔

would like to chat about this, but don't necessarily think it has to happen in this PR

View changes since this review

rust-bors · 2026-06-10T10:07:22Z

☀️ Try build successful (CI)
Build commit: ac2cd6c (ac2cd6c6bd6112f8ff087927638338b0d77a2756, parent: d56483a91d6cf5041351a3208b8d08f98f0c8b56)

rust-timer · 2026-06-10T10:48:25Z

Finished benchmarking commit (ac2cd6c): 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.6%	[0.1%, 1.3%]	32
Regressions ❌ (secondary)	0.5%	[0.1%, 2.1%]	35
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-5.1%	[-21.7%, -0.0%]	23
All ❌✅ (primary)	0.6%	[0.1%, 1.3%]	32

Max RSS (memory usage)

Results (primary -0.3%, 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)	2.7%	[2.5%, 2.8%]	2
Regressions ❌ (secondary)	4.3%	[0.6%, 15.6%]	5
Improvements ✅ (primary)	-2.3%	[-2.6%, -2.0%]	3
Improvements ✅ (secondary)	-2.9%	[-7.2%, -1.0%]	6
All ❌✅ (primary)	-0.3%	[-2.6%, 2.8%]	5

Cycles

Results (secondary -8.8%)

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.7%	[2.7%, 2.7%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-9.8%	[-21.2%, -2.5%]	11
All ❌✅ (primary)	-	-	0

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%]	23
Improvements ✅ (primary)	-0.1%	[-0.2%, -0.0%]	48
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.0%]	27
All ❌✅ (primary)	-0.0%	[-0.2%, 0.0%]	72

Bootstrap: 525.47s -> 527.211s (0.33%)
Artifact size: 400.80 MiB -> 401.22 MiB (0.11%)

lcnr

there are a few eager normalization changes in your PR which probably don't have to be here 🤔

I would really like to change the matches on ty::Alias which treat the alias as potentially normalizeable to explicitly check for "is_rigid" themselves. I dislike the way e.g. the normalization visitors currently just match on ty::Alias. For future PR

while there are a few things I kinda dislike about this PR as is, it is a large change and we can clean them up afterwards

View changes since this review

lcnr · 2026-06-11T10:09:13Z

-                                ty,
+                                // FIXME(rigid_aliases_marker): types coming out of `item_bounds`
+                                // are marked as non-rigid while the visited ty can be rigid.
+                                ty::set_aliases_to_non_rigid(tcx, ty),


as in, we relate non-rigid with rigid aliases here?

lcnr · 2026-06-11T10:12:17Z

 }

 /// Return whether we should consider the current place as a drop guard and skip reporting.
 fn maybe_drop_guard<'tcx>(


hmm, why does liveness use PostAnalysis at all?

It is running on mir_promoted and should just use the typing mode of its MIR body 🤔

No idea, but it does use PostAnalysis 😢

lcnr · 2026-06-11T10:13:53Z

+        // FIXME(rigid_aliases_marker): ideally we set aliases to non_rigid right after
+        // the typing mode is set to `PostAnalysis`.
+        // But modifying local decls in MIR body is inconvenient. And we can't fold
+        // `PlaceRef` in `checked_places`.


Suggested change

// FIXME(rigid_aliases_marker): ideally we set aliases to non_rigid right after

// the typing mode is set to `PostAnalysis`.

// But modifying local decls in MIR body is inconvenient. And we can't fold

// `PlaceRef` in `checked_places`.

// FIXME(rigid_aliases_marker): Liveness uses `TypingMode::PostAnalysis`

// even though its run on `mir_promoted` which is still

// in an earlier `TypingMode`. This is odd and we have to

// manually mark aliases as non-rigid here.

I think we just shouldn't use PostAnalysis here?

I can try with a different typing mode, perhaps PostBorrowckAnalysis? and we then don't need to change rigidness manually here.

I think changing rigidness and keeping this FIXME is fine. Should look into this in a separate PR though :>

lcnr · 2026-06-11T10:15:05Z

-        {
+        if let Ok(c) = self.tcx.try_normalize_erasing_regions(
+            self.typing_env,
+            Unnormalized::new_wip(ty::set_aliases_to_non_rigid(self.tcx, constant.const_)),


should set_aliases_to_non_rigid just return Unnormalized?

It could, but Unnormalized is kinda unwieldy as noted in its cons?

yeah, I think it results in a nicer temporary state to do this I think

lcnr · 2026-06-11T10:17:10Z

I would prefer that I think

lcnr · 2026-06-11T10:26:15Z

+pub fn eager_resolve_vars_with_infcx<Infcx: InferCtxtLike, T: TypeFoldable<Infcx::Interner>>(
+    delegate: &Infcx,
+    value: T,
 ) -> T {


do we need both of these or could we just change the signature of eager_resolve_vars and that's good enough

lcnr · 2026-06-11T10:26:38Z

        "directory into which to write optimization remarks (if not specified, they will be \
 written to standard error output)"),
+    renormalize_rigid_aliases: bool = (false, parse_bool, [TRACKED],
+        "do not skip rigid aliases in normalization"),


Suggested change

"do not skip rigid aliases in normalization"),

"do not skip rigid aliases in normalization for internal debugging"),

lcnr · 2026-06-11T10:27:23Z

+                    // FIXME: why don't we also instantiate const and region params with infer vars
+                    // here?


that fixme shouldn't be on the Alias branch 🤣

the reason we don't is "diagnostics code isn't soundness critical, wildly out of date, and poorly tested" 😁

lcnr · 2026-06-11T10:31:31Z

+// FIXME: This can't handle `AliasTerm`. Unsure if this is a problem in practice.
+// We can't assert about `AliasTerm` as well since it doesn't affect type flags.


that seems fine to me 😁

if you have an AliasTerm you should already know whether to treat it as rigid or not 😁

lcnr · 2026-06-11T10:32:43Z


        // Alias tend to mostly already be handled downstream due to normalization.
-        (ty::Alias(a), ty::Alias(b)) => {
+        (ty::Alias(a), ty::Alias(b)) if a.is_rigid == b.is_rigid => {


still relevant? 🤔

adwinwhite · 2026-06-11T12:23:06Z

I just saw the latest review comments right now. Will try to resolve them tomorrow.

rust-log-analyzer · 2026-06-11T12:54:34Z

The job x86_64-gnu-llvm-21 failed! Check out the build log: (web) (plain enhanced) (plain)

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


---- [mir-opt] tests/mir-opt/issue_99325.rs stdout ----
2 
3 | User Type Annotations
4 | 0: user_ty: Canonical { value: TypeOf(DefId(0:3 ~ issue_99325[d56d]::function_with_bytes), UserArgs { args: [&*b"AAAA"], user_self_ty: None }), max_universe: U0, var_kinds: [] }, span: $DIR/issue_99325.rs:13:16: 13:46, inferred_ty: fn() -> &'static [u8] {function_with_bytes::<&*b"AAAA">}
- | 1: user_ty: Canonical { value: TypeOf(DefId(0:3 ~ issue_99325[d56d]::function_with_bytes), UserArgs { args: [UnevaluatedConst { kind: Anon { def_id: DefId(0:8 ~ issue_99325[d56d]::main::{constant#1}) }, args: [], .. }], user_self_ty: None }), max_universe: U0, var_kinds: [] }, span: $DIR/issue_99325.rs:14:16: 14:68, inferred_ty: fn() -> &'static [u8] {function_with_bytes::<&*b"AAAA">}
+ | 1: user_ty: Canonical { value: TypeOf(DefId(0:3 ~ issue_99325[d56d]::function_with_bytes), UserArgs { args: [UnevaluatedConst { kind: Anon { def_id: DefId(0:8 ~ issue_99325[d56d]::main::{constant#1}) }, args: [], is_rigid: No, .. }], user_self_ty: None }), max_universe: U0, var_kinds: [] }, span: $DIR/issue_99325.rs:14:16: 14:68, inferred_ty: fn() -> &'static [u8] {function_with_bytes::<&*b"AAAA">}
6 |
7 fn main() -> () {
8     let mut _0: ();


thread '[mir-opt] tests/mir-opt/issue_99325.rs' panicked at src/tools/compiletest/src/runtest/mir_opt.rs:73:21:
Actual MIR output differs from expected MIR output /checkout/tests/mir-opt/issue_99325.main.built.after.32bit.mir
stack backtrace:
   5: __rustc::rust_begin_unwind
             at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panicking.rs:689:5
   6: core::panicking::panic_fmt
             at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/core/src/panicking.rs:80:14

rust-bors · 2026-06-12T06:58:04Z

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

lcnr

just realized. SolverRelating should not emit alias relate goals if the aliases are rigid but instead just relate them structurally 🤔

View changes since this review

rustbot assigned lcnr May 19, 2026