https://doc.rust-lang.org/beta/unstable-book/compiler-flags/codegen-backend.html
as i see it, the rust compiler does not guarantee the layout of dyn Trait objects to be consistent, even for two programs compiled with the same compiler version.
even if the vtable itself had a stable abi, it involves function pointers that accept #[repr(Rust)] structs.
won't this completely break in catastrophic ways if rust decides to reorder a single struct field?
All codegen backends within a single rustc version share the same layout computation code. This ensures that they are abi compatible with each other even though different rustc versions are not abi compatible with each other.
just because they share the same layout code doesn't mean that code will always produce the same result. it might, but i wouldn't want to assume that unless something officially documented it.
I think "not guaranteed" doesn't mean "non-deterministic".
the layout of any type is always deterministically calculated by the compiler, but the input information (mind you, not just the type definition at source code level) to this algorithm is intentionally left as implementation detail, thus it is not guaranteed for different types (with seemingly same definition at source code level) to have the same layout, this is so because the compiler wants to reserve the freedom to do (otherwise maybe impossible) optimizations.
Also as maintainer of the Cranelift backend I guarantee that the LLVM and Cranelift backend are ABI compatible with the exception of bugs. In other words any divergence that is reported to the Cranelift backend will be fixed.