[BUG] Invalid binding generation resurfacing after 0.70

[jgabaut]

I hit this issue due to a transitive dependency on bindgen 0.70 being bumped to 0.71 (and later 0.72.1):

• Bindgen >=0.58 produces an invalid union with both packed and align representation hints  #2159

I don't really know what changed in recent versions that could lead to this, but I first got the transitive dependency bumped to 0.72.1 to get the fix for:

• Missing fields in nested class with LLVM 22 #3264

Which did not fix my mingw-w64 CI fail.

• raylib in v5.5+ depends on bindgen 0.70 which did not surface the problem
• raylib v6.0.0-rc.2 bumped bindgen to 0.71, which suffers from
  • Missing fields in nested class with LLVM 22 #3264
  • I tried bumping to 0.72.1 to get the fix to Missing fields in nested class with LLVM 22 #3264, but this problem did not go away
    Using opaque_type or blocklist_type fixed it.

x86_64-w64-mingw32-gcc --version
x86_64-w64-mingw32-gcc (GCC) 16.1.0

clang --version
clang version 22.1.5

[jgabaut]

Since downgrading to bindgen 0.70 does not fix my CI fail, this could be due to the raylib 6.0+ edits to binding configuration, rather than a regression in bindgen >0.70 , but #2159 is still open so I figured it was worth cross-referencing context.

Edit:

Specifying that my error:

• did not involve specifically the packed + align side of things from Bindgen >=0.58 produces an invalid union with both packed and align representation hints  #2159
  • I haven't checked the contents of the CI filesystem, but the github mirror of mingw-w64 has a git blame of 14 years ago for this specific struct definition and I don't see it being packed there nor in my testing (see chore: opaque type __mingw_ldbl_type_t raylib-rs/raylib-rs#322 for more info)
  • but was on the same struct, probably the only union with a long double in the whole mingw-w64 stdlib headers (not checked info)

This other issue could also be related:

• long double becomes u128 #1549

[jgabaut]

I suspect this was due to:

• clang_macro_fallback doesn't propagate implicit --target to fallback translation unit #3352

Since the binding generation in raylib-rs is not setting the target explicitly.

Edit: I honestly can't tell what the "fallback translation unit" is, I tried googling it with clang prepended and also in double quotes but did not find insights.
Maybe my problem was closer to #1549?

I would refer to raylib-rs/raylib-rs#322 for more info over the __mingw_ldbl_type_t definition.

This landing in rust 1.77-1.78 could be related: https://blog.rust-lang.org/2024/03/30/i128-layout-update

But my dependency was already at MSRV 1.83~1.82 before the recent bump to 1.85 (more specifically, it went from edition = 2024 to rust-version = 1.85.0)

raylib-rs <6.0+ specifies edition = 2024 for the raylib-sys crate.
raylib-rs >6.0+ specifies rust-version = 1.85.0, which bumped the MSRV from 1.83~1.82

The rust blog link above mentions:

• __int128 stack calling conventions are incorrect on x86-64 llvm/llvm-project#41784
• i128 / u128 are not compatible with C's definition. rust#54341 (comment)

[ojeda]

So, if I understand correctly, you are hitting an issue in a project that uses raylib-sys (?), but it is unclear how to reproduce it.

Also, from your analysis, it is also unclear, in the end, when you started seeing this in the end, i.e. it was just bumping to a new version of raylib-sys? Or did you figure a bindgen version that did not suffer from this in the end?

In any case, all the context here may be good for others, but the key is to provide a reproducible example -- it seems you may have one (from a quick look at your linked PR to the Rust crate), so I would suggest copying here:

• The (ideally minimized) C header that generates __mingw_ldbl_type_t.
• The Rust code that gets generated by the latest bindgen (i.e. what you have for __mingw_ldbl_type_t).
• The error message you get when building it, and the details about it, e.g. does it only happen for mingw-w64?

And, yeah, it may simply be related to one more case of packed+aligned structs, but it would be good to have the means here to research it further if needed.

I hope that helps, and thanks!