Compile time layout tests

[GKFX]

This commit emits layout tests as compile-time assertions, rather than as unit tests. This allows them to be run in situations where running unit tests is unfeasible, i.e. cross-compiled code and nostd targets.

Fixes #2786. @ojeda - I noticed you tagged the feature request for Rust-for-Linux.

[emilio]

This looks great, though I think it's a requirement to make it the default to be able to tell how the values differ... Can we use format!() in the message or something along those lines?

[emilio]

(or does the assert macro print that already?)

[pvdrz]

There's no way to print such thing on const context AFAIK

[emilio]

I haven't been able to play with this yet but maybe we can abuse slice indexing to at least print the differences between actual and expected? E.g for [0u8][X - Y] or something like that which would panic if X was different to Y, and I would expect the compiler to print the bad index?

[pvdrz]

oh that's so hacky... I love it!

[GKFX]

Using slice indexing works. I've put the string as the expression in the array rather than 0u8 so it's visible.

[gabiganam]

The new code generated by this change triggers a false-positive unnecessary operation warning from rust-clippy.
Seems like the issue was already reported: rust-lang/rust-clippy#12817
And fixed: rust-lang/rust-clippy#12840
But wasn't released yet.

[Arnavion]

It also increased MSRV of the generated code to 1.77.0 which is the one that stabilized offset_of!

[GKFX]

The MSRV of the generated code is configurable with Builder::rust_target. If using Bindgen 0.70 and Rust < 1.77.0 then the relevant target will need to be set.

[Arnavion]

Ah yes, sorry for the noise.

[AlexTMjugador]

A seemingly-overlooked side effect of moving layout tests to constant expressions is that C code which gets translated to different bindings in different platforms may no longer compile on platforms different than the one the bindings were generated in. This is especially inconvenient when the platform-specific differences in size and alignment do not affect correctness.

For instance, this problem has caused Windows builds to fail for a project I maintain when using bindings generated under Linux. In this case, the discrepancies stem from the long type having different sizes on Windows and Linux, which is inconsequential for the purposes of my project, since such numeric types are referred to by their C aliases. Generating the bindings during the build for the current target plaform is not that practically feasible either, because that slows down compilation significantly and introduces additional build-time requirements.

As @GKFX noted, configuring bindgen to target Rust 1.73 restores the previous codegen behavior for size and alignment tests. However, discovering this workaround was difficult, as I had to dig through the repository to locate this PR, and I think it's a bad long-term solution. This workaround means the generated bindings won't ever be able to take advantage of features introduced in newer Rust versions, and it's reasonable to expect that bindgen maintainers may eventually drop support for targeting older Rust versions once doing so becomes enough of a burden.

Would it be feasible to make this behavior toggleable via an independent switch or, at the very least, document it more thoroughly? This could save others from encountering similar problems.

[GKFX]

Generating bindings on one platform and using them on another is inherently risky, and I personally feel that the layout tests are doing their job here by alerting you to that fact. The difference between longs may have worked out OK but that doesn't mean everything else will.

If you do expect the layout tests to fail I would disable them entirely with Builder::layout_tests rather than using the older version and just not running them.

[AlexTMjugador]

Thank you for the tip about disabling layout tests, it's indeed a much better solution for use cases like mine! I was initially reluctant to use it because I wanted to have layout test coverage for Linux and for the bindings that don't change between platforms, but I ended up not running such tests on Windows anyway because they failed, so your comment made me realize I was not compromising on much 👍

[pvdrz]

Generating bindings on one platform and using them on another is inherently risky, and I personally feel that the layout tests are doing their job here by alerting you to that fact. The difference between longs may have worked out OK but that doesn't mean everything else will.

I agree wholeheartedly with this. If you want to support different platforms, I think you should consider cfg gating your bindings in one way or another.

[AlexTMjugador]

I think you should consider cfg gating your bindings in one way or another.

I agree that's the most correct solution in general, but in my case doing so bloats the crate size and reduces its portability (realistically, I cannot be bothered to pregenerate bindings for every platform users may want to target, and generating bindings on build is not ideal) for no gain, as the only risk with the generated bindings for my project I can see are layout tests not being portable. I already took care of excluding types and functions that referred to libc internals and the like, for example.

[emilio]

We allow to disable layout tests altogether don't we? Maybe generate one for the architecture you test on with tests, one elsewhere without?