Change:
<ins> // Regression test for #121473 // Checks that no ICE occurs when `size_of` // is applied to a struct that has an unsized // field which is not its last field use std::mem::size_of; pub struct BadStruct { pub field1: i32, pub field2: str, // Unsized field that is not the last field //~^ ERROR the size for values of type `str` cannot be known at compilation time pub field3: [u8; 16], } enum BadEnum1 { Variant1 { field1: i32, field2: str, // Unsized //~^ ERROR the size for values of type `str` cannot be known at compilation time field3: [u8; 16], }, } enum BadEnum2 { Variant1( i32, str, // Unsized //~^ ERROR the size for values of type `str` cannot be known at compilation time [u8; 16] ), } enum BadEnumMultiVariant { Variant1(i32), Variant2 { field1: i32, field2: str, // Unsized //~^ ERROR the size for values of type `str` cannot be known at compilation time field3: [u8; 16], }, Variant3 } union BadUnion { field1: i32, field2: str, // Unsized //~^ ERROR the size for values of type `str` cannot be known at compilation time //~| ERROR field must implement `Copy` or be wrapped in `ManuallyDrop<...>` to be used in a union field3: [u8; 16], } // Used to test that projection type fields that normalize // to a sized type do not cause problems struct StructWithProjections<'a> { field1: <&'a [i32] as IntoIterator>::IntoIter, field2: i32 } pub fn main() { let _a = &size_of::<BadStruct>(); assert_eq!(size_of::<BadStruct>(), 21); let _a = &size_of::<BadEnum1>(); assert_eq!(size_of::<BadEnum1>(), 21); let _a = &size_of::<BadEnum2>(); assert_eq!(size_of::<BadEnum2>(), 21); let _a = &size_of::<BadEnumMultiVariant>(); assert_eq!(size_of::<BadEnumMultiVariant>(), 21); let _a = &size_of::<BadUnion>(); assert_eq!(size_of::<BadUnion>(), 21); let _a = &size_of::<StructWithProjections>(); assert_eq!(size_of::<StructWithProjections>(), 21); let _a = StructWithProjections { field1: [1, 3].iter(), field2: 3 }; } </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. --(reduced) (original) <details<summary<strongOriginal Code</strong</summary<p</p</detailsI guess the original code is mutated from , where the type of field of is tweaked from to . <!-- 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. --: with no other options <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsI can find various , but none of them has the same ICE location as this one.
Bisects to , but I guess it just made the ICE easier to reach. cc
Jup, here it is on stable:
Related to
Regression in nightly-2023-08-11 (...) Out of PRs merged in that range there were 3 rollups: and one PR that had to do with :

<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: SizeOf MIR operator called for unsized type p0fapiquery', 'error: internal compiler error: SizeOf MIR operator called for unsized type p0fapiquery' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [evaltoallocationraw] const-evaluating + checking [evaltoconstvalueraw] simplifying constant for the type system | = note: this failure-note originates in the macro (in Nightly builds, run with -Z macro-backtrace for more info) [mirdropselaboratedandconstchecked] elaborating drops for [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
claim
Reduced slightly more:
oof, this is something that has been working on before. If a struct's fields have errors, it's very hard to taint the MIR or const eval in order to not run at all. But changing const eval to be permissive of errors that should have caused const eval to never run is also not great. That said, it makes no sense that is considered unsized. Layout computation should probably just error out due to not being the last field. this is all under the assumption that is emitted in wfcheck and not somewhere else. If it is emitted somewhere else, we may be able to taint the context at the emission site.
It's being emitted only in wfcheck not anywhere else :(