Fix ICE in normalization during closure capture analysis (#149746) #149800

Delta17920 · 2025-12-09T07:15:47Z

This fixes an internal compiler error that occurred when normalizing associated types during closure capture analysis.

The Fix: Modified rustc_middle/src/ty/normalize_erasing_regions.rs to gracefully handle projection normalization failures instead of panicking when analyzing closure captures.

Regression Test: Added tests/ui/associated-types/normalization-ice-issue-149746.rs, a reproduction case involving complex associated type projections (<() as Owner>::Ty) that previously crashed the compiler. Verified it now emits a standard type error (E0277).

Fixes #149746

rustbot · 2025-12-09T07:15:51Z

r? @fee1-dead

rustbot has assigned @fee1-dead.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Delta17920 · 2025-12-09T07:21:38Z

r? compiler

rustbot · 2025-12-09T07:21:42Z

fmease is not on the review rotation at the moment.
They may take a while to respond.

rustbot · 2025-12-09T07:23:46Z

compiler-errors is not on the review rotation at the moment.
They may take a while to respond.

lcnr · 2025-12-09T08:17:46Z

compiler/rustc_middle/src/ty/normalize_erasing_regions.rs

+        let input = self.typing_env.as_query_input(arg);
+
+        // 2. Use unwrap_or(arg) to return the original arg if it fails
+        self.tcx.try_normalize_generic_arg_after_erasing_regions(input).unwrap_or(arg)


we're intentionally using a bug! here as we're in normalize_generic_arg_after_erasing_regions.

The issue happens in the caller:

we either have to change the caller to use try_normalize... to avoid this ICE if the error is unavoidable

or prevent this error entirely by not calling normalize_... for types which aren#t well-formed

Thanks for the feedback @lcnr ! I have reverted the global change in rustc_middle and moved the fix to compiler/rustc_hir_typeck/src/upvar.rs as requested. specifically, I updated the needs_drop closure within has_significant_drop_outside_of_captures to use try_normalize_erasing_regions; if normalization fails, it now conservatively returns false (assuming no significant drop) instead of panicking.

Delta17920 · 2025-12-10T16:55:41Z

@lcnr anything else that needs to be changed?

fmease · 2025-12-11T00:07:53Z

tests/ui/associated-types/normalization-ice-issue-149746.rs

@@ -0,0 +1,16 @@
+// edition: 2015..2021


Suggested change

// edition: 2015..2021

//@ edition: 2015..2021

The MCVE I've posted in #149746 (comment) which you're using here as a test, deliberately has an @ there: It's a compiletest directive.

this has not been resolved

Delta17920 · 2025-12-16T17:33:02Z

@lcnr anything else that needs to be changed?

Delta17920 · 2025-12-18T07:34:06Z

r? @fmease

rustbot · 2025-12-18T07:34:10Z

fmease is not on the review rotation at the moment.
They may take a while to respond.

lcnr · 2025-12-18T11:20:19Z

I am sorry that I did not quickly re-review this PR. For non-critical work, it is expected that reviewers sometimes take 1-2 weeks.

Pinging people after a few days is fine if the issue is blocking other important work or if it fixes a critical issue. Please be more patient going forward.

r? lcnr

Delta17920 · 2025-12-18T11:34:26Z

I am sorry that I did not quickly re-review this PR. For non-critical work, it is expected that reviewers sometimes take 1-2 weeks.

Pinging people after a few days is fine if the issue is blocking other important work or if it fixes a critical issue. Please be more patient going forward.

r? lcnr

sorry sorry, i will take care of this from the next time

lcnr

There's something a lot bigger here, which is why I didn't take the time to look at this PR until now.

At its core, a lot of code in the compiler assumes that if a type is well-formed, so are its fields. This is simply not true, neither currently nor in general:

currently there's #149283
in general, there's lcnr/random-rust-snippets#23

This is separate to the issue in this PR, where the struct itself is not well-formed and we don't emit an error for it. These we could handle by changing normalize_erasing_regions to emit a span_delayed_bug, returning an ty::Error instead. Doing that is kind of whatever however if the issue also just exists for otherwise well-formed programs.

Outside of codegen, using normalize_erasing_regions can pretty much always go wrong. Quickly looking through to source, the following additional calls to normalize_erasing_regions may also result in reachable ICE

rust/compiler/rustc_middle/src/ty/layout.rs

Line 545 in e951f47

let normalized = tcx.normalize_erasing_regions(typing_env, ty);

(we recur into struct fields)
rust/compiler/rustc_middle/src/ty/layout.rs

Line 906 in e951f47

let metadata = tcx.normalize_erasing_regions(

(should ICE for reference to alias as struct field)
pretty much all (indirect) uses of normalize_erasing_regions in CTFE and MIR opts can result in ICE as long as they happen in generic bodies
using normalize_erasing_regions in borrowck for the not explicitly mentioned fields of Foo { ..Default::default() } expressions should ICE
using normalize_erasing_regions in resolve_instance_raw ICEs mir opts and CTFE using it

I would kind of like to figure out a more general strategy here instead of fixing these issues as they crop up. Anyways, fine with this PR for now, but want to start a T-types discussion about this and think about a general solution here.

View changes since this review

lcnr · 2025-12-22T15:58:26Z

compiler/rustc_hir_typeck/src/upvar.rs

+            // If normalization fails, we assume it doesn't have a significant drop (false)
+            // to avoid crashing, allowing the compiler to emit the underlying type error later.
+            self.tcx
+                .try_normalize_erasing_regions(typing_env, ty)


can you instead replace the normalize_erasing_regions call in has_significant_drop with its try_ variant. r=me after.

Done! I've moved the fix to has_significant_drop itself, replacing normalize_erasing_regions with try_normalize_erasing_regions and returning false when normalization fails.

lcnr · 2025-12-23T09:52:08Z

compiler/rustc_middle/src/ty/util.rs

+                // FIX: Use try_normalize to avoid crashing. If it fails, return false.
+                tcx.try_normalize_erasing_regions(typing_env, query_ty)
+                    .map(|erased| tcx.has_significant_drop_raw(typing_env.as_query_input(erased)))
+                    .unwrap_or(false)


why false? in case the query_ty has infer we're currently conservatively returning true and we should the the same here

Ah, good point! I completely missed that 😭🤦‍♂️we're already returning true conservatively for the has_infer() case. You're right - we should be consistent here. Updated to return true instead to match that behavior.

rustbot · 2025-12-23T12:59:06Z

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.

lcnr · 2025-12-23T20:01:58Z

@bors r+ rollup

bors · 2025-12-23T20:02:01Z

📌 Commit ac448c9 has been approved by lcnr

It is now in the queue for this repository.

Rollup of 6 pull requests Successful merges: - #149800 (Fix ICE in normalization during closure capture analysis (#149746)) - #150182 (Don't export upstream monomorphizations from compiler-builtins) - #150216 (Tidying up tests/ui/issues 15 tests [6/N]) - #150308 (Update bors configuration) - #150314 (rustc-dev-guide subtree update) - #150319 (use new term in description of --target) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of #149800 - Delta17920:fix-ice-149746, r=lcnr Fix ICE in normalization during closure capture analysis (#149746) This fixes an internal compiler error that occurred when normalizing associated types during closure capture analysis. The Fix: Modified rustc_middle/src/ty/normalize_erasing_regions.rs to gracefully handle projection normalization failures instead of panicking when analyzing closure captures. Regression Test: Added tests/ui/associated-types/normalization-ice-issue-149746.rs, a reproduction case involving complex associated type projections (<() as Owner>::Ty<T>) that previously crashed the compiler. Verified it now emits a standard type error (E0277). Fixes #149746

Rollup of 6 pull requests Successful merges: - rust-lang/rust#149800 (Fix ICE in normalization during closure capture analysis (rust-lang/rust#149746)) - rust-lang/rust#150182 (Don't export upstream monomorphizations from compiler-builtins) - rust-lang/rust#150216 (Tidying up tests/ui/issues 15 tests [6/N]) - rust-lang/rust#150308 (Update bors configuration) - rust-lang/rust#150314 (rustc-dev-guide subtree update) - rust-lang/rust#150319 (use new term in description of --target) r? `@ghost` `@rustbot` modify labels: rollup

rustbot assigned fee1-dead Dec 9, 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. labels Dec 9, 2025

This comment has been minimized.

Sign in to view

rustbot assigned fmease Dec 9, 2025

rustbot assigned compiler-errors and unassigned fee1-dead and fmease Dec 9, 2025

rustbot assigned lcnr and unassigned compiler-errors Dec 9, 2025

This comment has been minimized.

Sign in to view

lcnr reviewed Dec 9, 2025

View reviewed changes

Delta17920 force-pushed the fix-ice-149746 branch from 3b0c42e to fc87a13 Compare December 9, 2025 09:41

This comment has been minimized.

Sign in to view

fmease reviewed Dec 11, 2025

View reviewed changes

Delta17920 requested review from fmease and lcnr December 11, 2025 00:38

rustbot assigned fmease and unassigned lcnr Dec 18, 2025

matthiaskrgr mentioned this pull request Dec 18, 2025

when asking a team for review, don't assign to people that are on vacation/off rust-lang/triagebot#2237

Open

rustbot assigned lcnr Dec 18, 2025

rustbot unassigned fmease Dec 18, 2025

lcnr reviewed Dec 22, 2025

View reviewed changes

Delta17920 force-pushed the fix-ice-149746 branch from badc3d2 to cce05f0 Compare December 22, 2025 17:51

This comment has been minimized.

Sign in to view

lcnr reviewed Dec 23, 2025

View reviewed changes

Fix ICE in normalization during closure capture analysis

ac448c9

Delta17920 force-pushed the fix-ice-149746 branch from cce05f0 to ac448c9 Compare December 23, 2025 12:59

bors 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 Dec 23, 2025

matthiaskrgr mentioned this pull request Dec 23, 2025

Rollup of 6 pull requests #150324

Merged

bors merged commit f6c6e84 into rust-lang:main Dec 24, 2025
11 checks passed

rustbot added this to the 1.94.0 milestone Dec 24, 2025

Uh oh!

Fix ICE in normalization during closure capture analysis (#149746) #149800

Fix ICE in normalization during closure capture analysis (#149746) #149800

Conversation

Delta17920 commented Dec 9, 2025 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Dec 9, 2025

Uh oh!

This comment has been minimized.

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

Uh oh!

Uh oh!

rustbot commented Dec 9, 2025

Uh oh!

rustbot commented Dec 9, 2025

Uh oh!

This comment has been minimized.

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

Delta17920 commented Dec 10, 2025

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!

Delta17920 commented Dec 16, 2025

Uh oh!

Delta17920 commented Dec 18, 2025

Uh oh!

rustbot commented Dec 18, 2025

Uh oh!

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

Uh oh!

Uh oh!

Delta17920 commented Dec 18, 2025

Uh oh!

lcnr left a comment • 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.

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rustbot commented Dec 23, 2025

Uh oh!

lcnr commented Dec 23, 2025

Uh oh!

bors commented Dec 23, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

Delta17920 commented Dec 9, 2025 •

edited by rustbot

Loading

Delta17920 commented Dec 9, 2025 •

edited

Loading

lcnr commented Dec 18, 2025 •

edited

Loading

lcnr left a comment •

edited

Loading