Auto-generated test failure

[nivkner]

This is the smallest case I got, based on clangs internal definition of max_align_t, in the header __stddef_max_align_t.h used in the libc header stddef:

typedef struct {
  long double __clang_max_align_nonce2
      __attribute__((__aligned__(__alignof__(long double
))));
} max_align_t;

Produces the following error:

thread 'header::bindgen_test_layout_max_align_t'
 panicked at 'assertion failed: `(left == right)`
  left: `8`,
 right: `16`: Size of: max_align_t', src/header.rs:10:5

system info:

rustc 1.27.0-nightly                                   
 binary: rustc                                         
  commit-hash: unknown
commit-date: unknown                                    
host: aarch64-linux-android                         
release: 1.27.0-nightly                             
LLVM version: 6.0



libclang: 6.0.0-2
bindgen 0.37.0

The commit is unknown because I'm using the rustc-nightly package for termux from the "its-pointless" repository.

[emilio]

Does it happen if you enable repr(align) with rust_target? Otherwise it's expected, we can't just represent 16 bytes of alignment.

I guess now that i128 / u128 are stable we could, but we have repr align too...

[nivkner]

How do I enable repr(align)? --rust-target only has rustc versions and setting it to nightly doesn't change anything.

[emilio]

Setting it to nightly, assuming nightly is new enough, should enable repr(align) support.

[emilio]

I assuming this worked? Otherwise I don't want to lose track of it

[nivkner]

tested again with a different system:

rustc 1.28.0-nightly (29ffe51e3 2018-05-23)
binary: rustc
commit-hash: 29ffe51e34ec0491806befadc4f820b132b50f9e
commit-date: 2018-05-23
host: x86_64-unknown-linux-gnu
release: 1.28.0-nightly
LLVM version: 6.0

built bindgen from git (commit ede60540247b7ffebaac880d5f978e079edb1c39) and used --rust-target nightly.
Still generates repr(C) for this code.

[emilio]

Yeah, I could repro this... long double is... fun, and I don't think it has a way we can represent it in rust other than f64...

[emilio]

This should be fixed now after #1391 and related work, as long as you use a rust target that supports repr(align).