Change:
IntegerExt, LayoutCx, LayoutError, LayoutOf, TyAndLayout, MAX_SIMD_LANES, }; use rustc_middle::ty::print::with_no_trimmed_paths; <del> use rustc_middle::ty::{self, AdtDef, EarlyBinder, GenericArgsRef, Ty, TyCtxt, TypeVisitableExt}; </del> <ins> use rustc_middle::ty::{ self, AdtDef, EarlyBinder, FieldDef, GenericArgsRef, Ty, TyCtxt, TypeVisitableExt, }; </ins> use rustc_session::{DataTypeKind, FieldInfo, FieldKind, SizeKind, VariantInfo}; use rustc_span::sym; use rustc_span::symbol::Symbol;

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 :(