Change:
layout::FieldPlacement::Array { stride, .. } => { let len = base.len(self)?; if field >= len { <del> // This can be violated because this runs during promotion on code where the // type system has not yet ensured that such things don't happen. </del> <ins> // This can be violated because the index (field) can be a runtime value // provided by the user. </ins> debug!("tried to access element {} of array/slice with length {}", field, len); throw_panic!(BoundsCheck { len, index: field }); } stride * field } layout::FieldPlacement::Union(count) => { <del> // FIXME(#64506) `UninhabitedValue` can be removed when this issue is resolved if base.layout.abi == Abi::Uninhabited { throw_unsup!(UninhabitedValue); } </del> assert!(field < count as u64, <del> "Tried to access field {} of union with {} fields", field, count); </del> <ins> "Tried to access field {} of union {:#?} with {} fields", field, base.layout, count); </ins> // Offset is always 0 Size::from_bytes(0) }

Discussion:
This ICEs on stable, probably since March 2018, but it requires the user to do UB in constants, so... I think a possible fix would be to enable validation in const eval (cc ), though we should benchmark the perf considerations around that first. Alternatively we can just not ICE here and instead emit an error. () Errors:
Interesting. ICEs in Miri with are also bugs, so I'd say doing more validation is not the right call. Do you have a backtrace? Which code is responsible for ICEing here and how hard/bad would it be to just error instead?
It's ICEing in and we could indeed just emit a UB error here, but it seems very... odd, since the field access check has very little to do with UB at a first glance. The layout is a union with zero fields, because it's essentially .
TBH this looks like a bug to me. That's the layout of which type, ? It should have a field, and it should not be a union. Cc
It's not a bug. Just like layout for a newtype with a single field is not a bug (E.g. ).
Precisely by analogy with , I think this is a bug. Your has a with exactly 1 field, matching what is declared. It does not have 2 fields which would be the case if it had a "pair layout". So, transparent layout changes the , but it does not change how many "fields" a type is considered to have. Similarly, has 3 fields in its layout, despite still being a . So, correspondingly, should have 1 field.
oh... right. Yea we should totally fix that
This being a layout bug would trivially break codegen, why is only miri affected?
Codegen might skip the field access because the type is uninhabited?
I wouldn't be so sure, codegen calls on layouts a lot without checking. Can the ICE print the whole ? That might be more useful here. EDIT: oh this might be why: we don't check the index at all:
yea but we can't use because that ICEs during const prop in the array case. I have a local branch that I'm playing with to get the entire picture
You can literally remove the assert to get the same effect.

But if the field count is wrong I'd rather have an assert in both places and fix the count (if possible).
The full is and so far I haven't figured out how that can happen
Ah, nevermind, I found it:
Ah so that's a micro-optimization. Maybe we should compute the right thing.
computes the layout for structs but keeps returning the never layout for enums without inhabited variants