`_BitInt` types lose their signedness and get widened to the next storage size

[lwz23]

Input C/C++ Header

_BitInt(24) f(_BitInt(24) v);

Bindgen Invocation

$ bindgen input.h

Actual Results

extern "C" {
    pub fn f(v: u32) -> u32;
}

Expected Results

A signed type, or an error.

_BitInt looks unhandled: libclang reports it as CXType_Unexposed, so it ends up in the opaque blob fallback, which picks a type by size from a table that only has unsigned integers in it. So every signed _BitInt(N) comes out unsigned, and widths that aren't a whole storage unit get widened — _BitInt(7) → u8, _BitInt(24) → u32, _BitInt(33) → u64. An extern _BitInt(24) x; declaration is dropped from the output entirely.

The widening isn't only cosmetic, because a sub-storage-width _BitInt carries an extension contract on x86-64. clang emits

declare signext i24 @f(i24 noundef signext)

while the binding lowers to a plain i32, so Rust reads bits that the ABI defines as sign extension. Calling f(0x7FFFFF) (increment the largest positive 24-bit value) returns -8388608 from C and 4286578688 through the binding. Nothing is printed on the way.

One thing worth not changing: unsigned _BitInt(128) currently maps to __BindgenOpaqueArray<u64, 2> and that's already correct — x86-64 gives _BitInt(128) alignment 8 rather than __int128's 16, and rust-lang/rust#137306 says i128 won't be guaranteed to match it.

$ bindgen --version
bindgen 0.72.1
$ clang --version
Ubuntu clang version 15.0.7
$ rustc --version
rustc 1.75.0

Target is x86_64-unknown-linux-gnu.

[lwz23]

__bf16 goes down the same path, and the consequence there is worse than lost signedness.

__bf16 bf_neg(__bf16 v);

unsafe extern "C" { pub fn bf_neg (v : u16) -> u16 ; }

Since it's a float rather than an integer, the surrogate also changes the psABI class:

C:    declare bfloat @bf_neg(bfloat noundef)
Rust: declare noundef zeroext i16 @bf_neg(i16 noundef zeroext)

bfloat is SSE-class and passed in xmm0, i16 is INTEGER-class, so a by-value call reads a register that was never written. Passing 1.5 (0x3FC0) through a function that flips the sign bit returns 0xBFC0 from C and 0xA780 through the binding, again with nothing printed.

Worth noting for anyone looking at a fix: this one isn't reachable from #2403's never_by_value, because that analysis matches TypeKind::Float and __bf16 doesn't get that far — it arrives as an opaque blob from the same fallback as _BitInt.

_Accum and _Fract (with -ffixed-point) land in the fallback too, becoming u32/u16. Their ABI class happens to be correct, so only the scale interpretation is lost there.

Same environment as above: bindgen 0.72.1, clang 15.0.7, rustc 1.75.0, x86_64-unknown-linux-gnu.