Skip to content

Conversation

@ShoyuVanilla
Copy link
Member

@ShoyuVanilla ShoyuVanilla commented Nov 12, 2025

Fixes #148192

The ICE comes from the following line, calling normalize_erasing_regions to a projection type whose trait bound is not met:

pub(crate) fn variant_sub_tys(
&self,
ty: RevealedTy<'tcx>,
variant: &'tcx VariantDef,
) -> impl Iterator<Item = (&'tcx FieldDef, RevealedTy<'tcx>)> {
let ty::Adt(_, args) = ty.kind() else { bug!() };
variant.fields.iter().map(move |field| {
let ty = field.ty(self.tcx, args);
// `field.ty()` doesn't normalize after instantiating.
let ty = self.tcx.normalize_erasing_regions(self.typing_env, ty);

The above function is called while trying to lint missing match arms, or scrutinize ctors of missing(not necessary error) match arms.

So, the following code can trigger ICEs.

trait WhereTrait {
    type Type;
}

fn foo(e: Enum) {
    match e {
        Enum::Map(_) => (), // ICE, while trying to lint missing arms
    }

    if let Enum::Map(_) = e {} // ICE, while trying to scrutinize missing ctors (even worse)
}

enum Enum {
    Map(()),
    Map2(<() as WhereTrait>::Type),
}

This ICE won't be triggered with the following code, as this is filtered out before check_match as the existence of ill-formed type inside the variant marks the body as tainted by error in hir_typeck, but for the above code, the hir_typeck complains nothing because everything it sees is locally correct.

fn foo(e: Enum) {
    match e {
        Enum::Map2(_) => (), // No ICE
    }
}

I've considered visiting and wf checking for the match scrutinee before entering check_match, but that might regress the perf and I think just emitting delayed bug would enough as the normalization failure would be originated by other errors like ill-formdness.

@rustbot
Copy link
Collaborator

rustbot commented Nov 12, 2025

Some changes occurred in exhaustiveness checking

cc @Nadrieril

@rustbot 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 Nov 12, 2025
@rustbot
Copy link
Collaborator

rustbot commented Nov 12, 2025

r? @chenyukang

rustbot has assigned @chenyukang.
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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

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.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ICE: Failed to normalize std::option::Option<Alias(Projection, AliasTy

3 participants