[ICE]: Miri/consteval assertion failure due to transmuting types with HRTB

[theemathas]

Code

The ICE occurs when running the following code in Miri.

use std::mem::transmute;

type F1 = for<'a> fn(&'a ());
type F2 = fn(&'static ());

trait Trait {
    type Assoc;
}

impl Trait for F1 {
    type Assoc = i64;
}
#[expect(coherence_leak_check)]
impl Trait for F2 {
    type Assoc = [i32; 2];
}

struct Thing<T: Trait>(T::Assoc);

fn foo(x: Thing<F1>) -> Thing<F2> {
    // This transmute is legal: The two types have the same size.
    unsafe { transmute(x) }
}

fn main() {
    foo(Thing(1i64));
}

cc @RalfJung @lcnr

Meta

Reproducible on the playground with version 1.97.0-nightly (2026-04-17 e9e32aca5a4ffd08cbc2)

Error output

thread 'rustc' (41) panicked at /rustc-dev/e9e32aca5a4ffd08cbc29547b039d64b92a2c03b/compiler/rustc_const_eval/src/interpret/eval_context.rs:186:13:
assertion `left == right` failed
  left: Layout { size: Size(8 bytes), align: AbiAlign { abi: Align(8 bytes) }, backend_repr: Scalar(Initialized { value: Int(I64, true), valid_range: 0..=18446744073709551615 }), fields: Arbitrary { offsets: [Size(0 bytes)], in_memory_order: [0] }, largest_niche: None, uninhabited: false, variants: Single { index: 0 }, max_repr_align: None, unadjusted_abi_align: Align(8 bytes), randomization_seed: 3972586742148095437 }
 right: Layout { size: Size(8 bytes), align: AbiAlign { abi: Align(4 bytes) }, backend_repr: Memory { sized: true }, fields: Arbitrary { offsets: [Size(0 bytes)], in_memory_order: [0] }, largest_niche: None, uninhabited: false, variants: Single { index: 0 }, max_repr_align: None, unadjusted_abi_align: Align(4 bytes), randomization_seed: 3972305267171450315 }

Backtrace

stack backtrace:
   0:     0x7cfab401c93b - <<std[ab5dd23a62e5ebc5]::sys::backtrace::BacktraceLock>::print::DisplayBacktrace as core[6403ce58e4e00ac6]::fmt::Display>::fmt
   1:     0x7cfab462e988 - core[6403ce58e4e00ac6]::fmt::write
   2:     0x7cfab4033936 - <std[ab5dd23a62e5ebc5]::sys::stdio::unix::Stderr as std[ab5dd23a62e5ebc5]::io::Write>::write_fmt
   3:     0x7cfab3ff2c18 - std[ab5dd23a62e5ebc5]::panicking::default_hook::{closure#0}
   4:     0x7cfab400ffa3 - std[ab5dd23a62e5ebc5]::panicking::default_hook
   5:     0x7cfab2fe3abc - std[ab5dd23a62e5ebc5]::panicking::update_hook::<alloc[6b8407d2afd8426e]::boxed::Box<rustc_driver_impl[a6df73e506a0ee75]::install_ice_hook::{closure#1}>>::{closure#0}
   6:     0x7cfab4010282 - std[ab5dd23a62e5ebc5]::panicking::panic_with_hook
   7:     0x7cfab3ff2cd8 - std[ab5dd23a62e5ebc5]::panicking::panic_handler::{closure#0}
   8:     0x7cfab3fe7239 - std[ab5dd23a62e5ebc5]::sys::backtrace::__rust_end_short_backtrace::<std[ab5dd23a62e5ebc5]::panicking::panic_handler::{closure#0}, !>
   9:     0x7cfab3ff473d - __rustc[8d41933af5f8f17a]::rust_begin_unwind
  10:     0x7cfab0af366c - core[6403ce58e4e00ac6]::panicking::panic_fmt
  11:     0x7cfab289e8d3 - core[6403ce58e4e00ac6]::panicking::assert_failed_inner
  12:     0x7cfab2ef35fe - core[6403ce58e4e00ac6]::panicking::assert_failed::<rustc_abi[5dc903a390f6c5ae]::layout::ty::Layout, rustc_abi[5dc903a390f6c5ae]::layout::ty::Layout>
  13:     0x7cfab5004e9b - rustc_const_eval[eca131647ee9c56c]::interpret::eval_context::mir_assign_valid_types
  14:     0x571f064b8ee5 - <rustc_const_eval[eca131647ee9c56c]::interpret::eval_context::InterpCx<miri[ce74c2dd16ee6ac8]::machine::MiriMachine>>::copy_op_no_validate::<rustc_const_eval[eca131647ee9c56c]::interpret::operand::OpTy<miri[ce74c2dd16ee6ac8]::machine::Provenance>, rustc_const_eval[eca131647ee9c56c]::interpret::place::PlaceTy<miri[ce74c2dd16ee6ac8]::machine::Provenance>>
  15:     0x571f065257b6 - <rustc_const_eval[eca131647ee9c56c]::interpret::eval_context::InterpCx<miri[ce74c2dd16ee6ac8]::machine::MiriMachine>>::cast
  16:     0x571f0652a25a - <rustc_const_eval[eca131647ee9c56c]::interpret::eval_context::InterpCx<miri[ce74c2dd16ee6ac8]::machine::MiriMachine>>::eval_rvalue_into_place
  17:     0x571f0661e0c0 - <rustc_const_eval[eca131647ee9c56c]::interpret::eval_context::InterpCx<miri[ce74c2dd16ee6ac8]::machine::MiriMachine> as miri[ce74c2dd16ee6ac8]::concurrency::thread::EvalContextExt>::run_threads
  18:     0x571f065a4312 - miri[ce74c2dd16ee6ac8]::eval::eval_entry
  19:     0x571f066dfcf9 - <miri[9a99b3dba452f193]::MiriCompilerCalls as rustc_driver_impl[a6df73e506a0ee75]::Callbacks>::after_analysis
  20:     0x7cfab57b0a99 - rustc_interface[c0ce4ed09eeec30a]::interface::run_compiler::<(), rustc_driver_impl[a6df73e506a0ee75]::run_compiler::{closure#0}>::{closure#1}
  21:     0x7cfab5785fca - std[ab5dd23a62e5ebc5]::sys::backtrace::__rust_begin_short_backtrace::<rustc_interface[c0ce4ed09eeec30a]::util::run_in_thread_with_globals<rustc_interface[c0ce4ed09eeec30a]::util::run_in_thread_pool_with_globals<rustc_interface[c0ce4ed09eeec30a]::interface::run_compiler<(), rustc_driver_impl[a6df73e506a0ee75]::run_compiler::{closure#0}>::{closure#1}, ()>::{closure#0}, ()>::{closure#0}::{closure#0}, ()>
  22:     0x7cfab57866ad - <std[ab5dd23a62e5ebc5]::thread::lifecycle::spawn_unchecked<rustc_interface[c0ce4ed09eeec30a]::util::run_in_thread_with_globals<rustc_interface[c0ce4ed09eeec30a]::util::run_in_thread_pool_with_globals<rustc_interface[c0ce4ed09eeec30a]::interface::run_compiler<(), rustc_driver_impl[a6df73e506a0ee75]::run_compiler::{closure#0}>::{closure#1}, ()>::{closure#0}, ()>::{closure#0}::{closure#0}, ()>::{closure#1} as core[6403ce58e4e00ac6]::ops::function::FnOnce<()>>::call_once::{shim:vtable#0}
  23:     0x7cfab578752c - <std[ab5dd23a62e5ebc5]::sys::thread::unix::Thread>::new::thread_start
  24:     0x7cfaaf28aaa4 - <unknown>
  25:     0x7cfaaf317a64 - clone
  26:                0x0 - <unknown>

error: the compiler unexpectedly panicked. This is a bug

note: we would appreciate a bug report: https://github.com/rust-lang/miri/issues/new

note: please make sure that you have updated to the latest nightly

note: please attach the file at `/playground/rustc-ice-2026-04-18T08_20_17-13.txt` to your bug report

note: rustc 1.97.0-nightly (e9e32aca5 2026-04-17) running on x86_64-unknown-linux-gnu

note: compiler flags: --crate-type bin -C embed-bitcode=no -C codegen-units=1 -C debuginfo=2 -Z miri-disable-isolation

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
end of query stack

Miri caused an ICE during evaluation. Here's the interpreter backtrace at the time of the panic:
note: the place in the program where the ICE was triggered
  --> src/main.rs:22:14
   |
22 |     unsafe { transmute(x) }
   |              ^^^^^^^^^^^^
   |
   = note: stack backtrace:
           0: foo
               at src/main.rs:22:14: 22:26
           1: main
               at src/main.rs:26:5: 26:21
           2: <fn() as std::ops::FnOnce<()>>::call_once - shim(fn())
               at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5: 250:71
           3: std::sys::backtrace::__rust_begin_short_backtrace::<fn(), ()>
               at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/backtrace.rs:166:18: 166:21
           4: std::rt::lang_start::<()>::{closure#0}
               at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:206:18: 206:75
           5: std::ops::function::impls::<impl std::ops::FnOnce<()> for &dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe>::call_once
               at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:287:13: 287:31
           6: std::panicking::catch_unwind::do_call::<&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe, i32>
               at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:581:40: 581:43
           7: std::panicking::catch_unwind::<i32, &dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe>
               at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:544:19: 544:88
           8: std::panic::catch_unwind::<&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe, i32>
               at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:359:14: 359:40
           9: std::rt::lang_start_internal::{closure#0}
               at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:175:24: 175:49
           10: std::panicking::catch_unwind::do_call::<{closure@std::rt::lang_start_internal::{closure#0}}, isize>
               at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:581:40: 581:43
           11: std::panicking::catch_unwind::<isize, {closure@std::rt::lang_start_internal::{closure#0}}>
               at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:544:19: 544:88
           12: std::panic::catch_unwind::<{closure@std::rt::lang_start_internal::{closure#0}}, isize>
               at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:359:14: 359:40
           13: std::rt::lang_start_internal
               at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:171:5: 193:7
           14: std::rt::lang_start::<()>
               at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:205:5: 210:6

[RalfJung]

That assertion is part of the check for ensuring that an assignment is valid. (I assume this would also fail the MIR validator?) It looks like the return type of the transmute does not properly match the type of the local it gets assigned into?

[RalfJung]

So what happens is that Thing<for<'a> fn(&'a ())> and Thing<fn(&())> are considered subtypes of each other, but they have different alignment. They also have a different backend_repr; one is a Scalar type while the other needs Memory representation. I don't think it is correct to consider such types subtypes of each other?

Cc @oli-obk @BoxyUwU

[theemathas]

@RalfJung That sounds wrong. Thing is invariant due to the associated type.

[RalfJung]

What can I say -- that assertion is only ever hit after types are already confirmed to be subtypes.

rust/compiler/rustc_const_eval/src/interpret/eval_context.rs

Lines 175 to 187 in 18d118a

	// Type-changing assignments can happen when subtyping is used. While
	// all normal lifetimes are erased, higher-ranked types with their
	// late-bound lifetimes are still around and can lead to type
	// differences.
	if util::relate_types(tcx, typing_env, Variance::Covariant, src.ty, dest.ty) {
	// Make sure the layout is equal, too -- just to be safe. Miri really
	// needs layout equality. For performance reason we skip this check when
	// the types are equal. Equal types *can* have different layouts when
	// enum downcast is involved (as enum variants carry the type of the
	// enum), but those should never occur in assignments.
	if cfg!(debug_assertions) || src.ty != dest.ty {
	assert_eq!(src.layout, dest.layout);
	}

[theemathas]

Doing the transmute in consteval, expectedly, also ICEs.

Code

use std::mem::transmute;

type F1 = for<'a> fn(&'a ());
type F2 = fn(&'static ());

trait Trait {
    type Assoc;
}

impl Trait for F1 {
    type Assoc = i64;
}
#[expect(coherence_leak_check)]
impl Trait for F2 {
    type Assoc = [i32; 2];
}

struct Thing<T: Trait>(T::Assoc);

const fn foo(x: Thing<F1>) -> Thing<F2> {
    // This transmute is legal: The two types have the same size.
    unsafe { transmute(x) }
}

fn main() {
    const { foo(Thing(1i64)); }
}