test-stylo failure in infra

[Ms2ger]

test-stylo --release seems to consistently fail on linux-rel-css with

---- gecko_bindings::structs::bindgen_test_layout_nsIDocument stdout ----
    thread 'gecko_bindings::structs::bindgen_test_layout_nsIDocument' panicked at 'assertion failed: `(left == right)` (left: `952`, right: `944`)', /home/servo/buildbot/slave/linux-rel-css/build/components/style/gecko_bindings/structs_release.rs:3165
stack backtrace:
   1:     0x7ff2ccd8ef39 - std::sys::backtrace::tracing::imp::write::h00e948915d1e4c72
   2:     0x7ff2ccd92eac - std::panicking::default_hook::_{{closure}}::h7b8a142818383fb8
   3:     0x7ff2ccd92084 - std::panicking::default_hook::h41cf296f654245d7
   4:     0x7ff2ccd927e8 - std::panicking::rust_panic_with_hook::h4cbd7ca63ce1aee9
   5:     0x7ff2ccd92642 - std::panicking::begin_panic::h93672d0313d5e8e9
   6:     0x7ff2ccd925b0 - std::panicking::begin_panic_fmt::hd0daa02942245d81
   7:     0x7ff2ccd4e797 - style::gecko_bindings::structs::bindgen_test_layout_nsIDocument::ha6b566dd1eada7ac
   8:     0x7ff2ccd5998b - _<F as alloc..boxed..FnBox<A>>::call_box::hd5b7ed3c754c2638
   9:     0x7ff2ccd52c4f - std::panicking::try::do_call::h63a911edf59441a1
  10:     0x7ff2ccd9a996 - __rust_maybe_catch_panic
  11:     0x7ff2ccd5934a - _<F as alloc..boxed..FnBox<A>>::call_box::h3db4d78fb37007ad
  12:     0x7ff2ccd90d92 - std::sys::thread::Thread::new::thread_start::h4c0ad33b336bc6ea
  13:     0x7ff2cc6fc183 - start_thread
  14:     0x7ff2cc21337c - clone
  15:                0x0 - <unknown>

@emilio @Manishearth

[Manishearth]

Yeah, @heycam is looking into this. No idea how it happened, the binding sync is gated on this

[Manishearth]

Oh, probably because we started gating on test-stylo --release very recently

[heycam]

It looks like the m-c commit causing trouble is this one: mozilla/gecko-dev@81f82ea

@emilio: in nsIDocument, we have a StyleBackendType followed by a bunch of bool mXXX : 1 members. Those bools are collapsed into a single u64. Could it be that the packing of the u8-sized enum next to the u64 is different from C++'s packing of the uint8_t-sized enum next to the bitfield?

[heycam]

#13851 is to land a workaround for this.