Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

The Miri subtree was changed

cc @rust-lang/miri

@lcnr turns out that using the trait system here is not sufficient, the test still fails with this PR...

Ah never mind, I missed one place where we are using !=.

... but even if I fix that, the issue remains. These two do not seem to be considered equal:

Binder { value: std::ops::FnMut<(<[std::boxed::Box<i32>] as std::ptr::Pointee>::Metadata,)>, bound_vars: [Region(BrNamed(DefId(0:9 ~ issue_miri_3541_dyn_vtable_trait_normalization[e6e3]::EmplacerFn::'b), 'b))] }
Binder { value: std::ops::FnMut<(usize,)>, bound_vars: [] }

the error is

error: there were 1 unmatched diagnostics
  --> tests/pass/issues/issue-miri-3541-dyn-vtable-trait-normalization.rs:23:24
   |
23 |         unsafe { &mut *((emplacer_fn as *mut EmplacerFn<'a, T>) as *mut Self) }
   |                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Error: Undefined Behavior: constructing invalid value: wrong trait in wide pointer vtable: expected `std::ops::FnMut(<[std::boxed::Box<i32>] as std::ptr::Pointee>::Metadata)`, but encountered `std::ops::FnMut<(usize,)>`
   |

So just normalizing and then using == does not work?

If the types are fully concrete, then they should be structurally equal after normalizing, anonymizing bound vars, and erasing all other regions. Breaking this assumption can result in linker errors. In general, you still need to handle types whose bound vars have a different order however.

While I can't think of any other causes for types to be semantically equal but not structurally rn, it still feels wrong to not use proper equality here.

Makes sense. This seems to work, thanks!

@rustbot ready

@bors r+

📌 Commit 3757136 has been approved by oli-obk

It is now in the queue for this repository.