Recent 32-bit transmute regression

[MagaTailor]

Compiling crossbeam v0.1.6
.cargo/registry/src/github.com-1ecc6299db9ec823/crossbeam-0.1.6/src/sync/seg_queue.rs:34:29: 34:43 error: transmute called with differently sized types: [usize; 32] (1024 bits) to [std::sync::atomic::AtomicBool; 32] (256 bits) [E0512]
.cargo/registry/src/github.com-1ecc6299db9ec823/crossbeam-0.1.6/src/sync/seg_queue.rs:34             ready: unsafe { mem::transmute([0usize; SEG_SIZE]) },
                                                                                                                                                       ^~~~~~~~~~~~~~
.cargo/registry/src/github.com-1ecc6299db9ec823/crossbeam-0.1.6/src/sync/seg_queue.rs:34:29: 34:43 help: run `rustc --explain E0512` to see a detailed explanation
error: aborting due to previous error

Rev d91f8ab0f seems to still work ok.

[durka]

This is because of #33579.

[durka]

cc @aturon (author of crossbeam)

The current version of crossbeam (0.2.9) does compile with current nightly.

[nagisa]

I believe transmute breaking is not considered a breaking change, especially because the language explicitly does not specify various details to ABI, type layout, etc etc.

[MagaTailor]

It's coming from the mandel benchmark as it currently is. AFAIC fixing the deps would be enough but simple_parallel still depends on 0.1.6 @willi-kappler?

[durka]

Regardless of how major it is officially, it was an untagged breaking change, which probably should have been cratered to assess usage. Hopefully there's still time to do that before the trains leave.

[bluss]

There's a bug report here (more or less) huonw/simple_parallel/issues/9

[sfackler]

@durka Should we really flag any change that alters the size of a type as a breaking change?

[durka]

It seems like a tautological question to me. "Is this change, which broke code in the wild, a breaking change?" I don't think we should release Rust 2.0 to change the size of AtomicBool, no. But apparently more caution was warranted when merging this change. Maybe simple_parallel is the only crate it breaks, maybe not, who knows? When the size of fn types changed, transmutes of them turned out to be widespread so there is a warning period.

As a slightly separate issue, we shouldn't be transmuting any types that aren't #[repr(C)], but there is no warning when you do (I think there should be). And perhaps the size of a #[repr(C)] type should be considered a stability guarantee?

[arielb1]

@durka

LLVM upgrades randomly break code that relies on undefined behaviour. Even code in the wild. We do not list that in relnotes. I think this case is pretty similar - the size and layout of Rust types is an implementation detail, and randomly transmuting things is hacky.