This addresses the underlying issue identified in #1671, that size_t
(integer that can hold any object size) isn't guaranteed to match usize,
which is defined more like uintptr_t (integer that can hold any
pointer). However, on almost all platforms, this is true, and in fact
Rust already uses usize extensively in contexts where size_t would be
more appropriate, such as slice indexing. So, it's better for ergonomics
when interfacing with C code to map the C size_t type to usize. (See
also discussion in rust-lang/rust#65473 about how usize really should be
defined as size_t, not uintptr_t.)
The previous fix for #1671 removed the special case for size_t and
defaulted to binding it as a normal typedef. This change effectively
reverts that and goes back to mapping size_t to usize (and ssize_t to
isize), but also ensures that if size_t is emitted, the typedef'd type
of size_t in fact is compatible with usize (defined by checking that the
size and alignment match the target pointer width). For (hypothetical)
platforms where this is not true, or for compatibility with the default
behavior of bindgen between 0.53 and this commit, onwards, you can
disable this mapping with --no-size_t-is-usize.
libclang's API does not provide a straightforward way to check for
this, and calling clang_getFieldDeclBitWidth is actively unsafe in
this case. See https://github.com/llvm/llvm-project/issues/56644
We probably can't generate reasonable bindings for such a type, so
make the binding opaque.
Ideally libclang would report if the bit width could not be
evaluated. Unfortunately making such a change would mean bumping the
minimum libclang version from 6.0 to 15.0.
Instead, add logic to traverse the AST subtree starting from the
field's bit width specifier looking for template parameters. If we
find one, we make the resulting type opaque.
Generated code needs some sorting in a way that is
semantically appealing. The request[1] asks for basic
sorting like "types are declared first, then all structs,
then all consts, then all function signatures, etc.
[1] https://github.com/rust-lang/rust-bindgen/issues/1743
Signed-off-by: Amanjeev Sethi <aj@amanjeev.com>
Co-authored-by: Christian Poveda <christian.poveda@ferrous-systems.com>
Co-authored-by: Darren Kulp <darren@kulp.ch>
