Avoid inserting invalid Subtype casts when types don't relate

[reddevilmidzy]

close: #154748
close: #154750

[reddevilmidzy]

I first tried fixing this during literal-to-const lowering, but that either changed the existing diagnostics or introduced additional delayed-bug ICEs.

The type mismatch is already diagnosed earlier, so this instead makes known_panics_lint bail out on incompatible layouts during const propagation to avoid the ICE while preserving the current errors.

[reddevilmidzy]

r? @BoxyUwU

[rustbot]

BoxyUwU is currently at their maximum review capacity.
They may take a while to respond.

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[oli-obk]

This fixes the symptom, not the issue itself. Why do we even get here after the error is reported?

Oh I think I may have found it: https://github.com/rust-lang/rust/pull/152001/changes#r3224335944

View changes since the review

[reddevilmidzy]

Thanks for taking a look!

For this testcase, lower_const_arg_literal does not hit the None branch. lit_to_const returns Some(value), so the literal keeps its own type, and the mismatch is only rejected later by the ConstArgHasType obligation.

add_subtyping_projections then turns the mismatched assignment into a CastKind::Subtype, even though the types are not actually related. So instead of guarding in known_panics_lint, I changed add_subtyping_projections to avoid inserting a Subtype cast for this kind of unrelated mismatch.

[BoxyUwU]

in theory this overlaps with #154853 there we also are solving the problem of type const normalization changing types of values causing ICEs in later parts of the compiler 🤔

[reddevilmidzy]

in theory this overlaps with #154853 there we also are solving the problem of type const normalization changing types of values causing ICEs in later parts of the compiler 🤔

Ah, you're right. I checked out #154853 and confirmed that the ICE no longer occurs there either. I'll close this PR. Thanks!

[BoxyUwU]

ah cool, sorry for not realising sooner