Change:
<ins> // This test verifies that we do not ICE due to MIR inlining in case of normalization failure // in a projection. // // compile-flags: --crate-type lib -C opt-level=3 // build-pass pub trait Trait { type Associated; } impl<T> Trait for T { type Associated = T; } pub struct Struct<T>(<T as Trait>::Associated); pub fn foo<T>() -> Struct<T> where T: Trait, { bar() } #[inline] fn bar<T>() -> Struct<T> { Struct(baz()) } fn baz<T>() -> T { unimplemented!() } </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --ICE is triggered when building in file in release mode. I'm not able to reproduce when building in debug mode. In my situation, the crate is built as part of the dependency tree for a binary crate. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc this seems like those mir-inliner bugs :thinking:
Bisected to which is likely (similar as issues and ).
Saw a couple of these in Crater, though typically with some other ICEs too (which is why I didn't file bugs). But tagging as 1.64 and beta regression.
For the record, that PR probably revealed this bug but is likely not the cause of it.
Indeed, that's the "usual" normalization failure ICE we have with the MIR inliner. When enabling the MIR inliner, I only a check that we don't have such type mismatch at the signature, but I did not attempt to check all types that appear in the MIR for such mismatch. If we want to fully avoid this ICE, we'd need to fully visit the callee body to check for those type mismatches. do you know if progress has been made on the normalization front?
Hmm, maybe this is fixed by , but I don't have time to investigate this right now. Edit: It's not fixed.
Do you think it may make sense to disable the MIR inliner on beta to give it some more time to bake? I think it was switched on mid-cycle in 1.64, right?
I qualify this as a bug in type normalization that MIR validation exposes. It's not a bug in the MIR inliner.

There are 3 ways to address this: more exceptions to the MIR inliner to avoid those bugs (easy but cumbersome, ); type normalization (very hard); MIR validation (tentative in ); validating MIR in released compilers but keep doing it on tests (very easy). However, I don't think that disabling the MIR inliner will help.
Stopping to validate MIR sounds like a really bad idea to me. MIR validation (in released compilers) has caught many critical issues already like (I found it while investigating a MIR validation failure that someone found in the wild because the mir typeck found something typeck let through) and the most recent let_chains problem which was also found because of a MIR validation ICE.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Reduced example: label S-bug-has-mcve
Weird, this one crashes with but I couldn't get this to trigger with just mir-opt-levels :thinking: