* --default-macro-constant-type could be 'signed' or 'unsigned'
* Its default value is 'unsigned' to use u32/u64
for C macro constants that fit into the u32/u64 ranges.
* For old C libraries that use macros as int/long parameter
and/or return value types, their macros are better declared
as i32/i64 if the values fit the i32/i64 ranges,
to be compatible with c_int/c_long types.
They can use "--default-macro-constant-type signed"
It seems libclang sometimes doesn't expose the right paramdecl cursors.
This should be reported upstream, but it's easy enough to workaround. It
loses the parameter names which is a bit unfortunate but...
Fixes#1778
By not generating various code for it.
In the future, we could improve on this by splitting contiguous bitfield units,
if needed, so that we can implement them without dealing with rust array derive
limits.
Fixes#1718
Before repr(align), we could only safely guarantee up to 8-bytes of alignment (I
think the pointer-width check is a more conservative way of doing that, in
practice, because I _think_ u64 is 8-byte aligned even for smaller targets).
So when we may generate a potentially-under-aligned struct, we always used to
pad it so as to guarantee that at least the size (and thus reads from rust for
C-allocated structs) was fine.
But if we support repr(align), then the above is always unneeded.
When a #defined token was used before a namespace, like so (#1676):
#define nssv_inline_ns inline
nssv_inline_ns namespace literals {}
bindgen would crash when encountering the unknown token preceding the
namespace token. This is because we don't get to see "past" the ifdef to
the underlying token. The true fix to this is to find a way to extract
ifdef info through clang, but for the time being we simply change the
panic into a warning when such a token is encountered, and then proceed
as if it were empty.
Fixes#1676.
Flexible array members are represented in the generated binding by a
struct __IncompleteArrayField<T>. Since such members do not contain any
information about how big they are, it is impossible to automatically
clone or copy them, either in C or rust.
Fixes#1431.
The following structs have different names for C and C++. In case of C
they are visible as `foo` and `bar`. In case of C++ they are visible as
`foo` and `foo::bar`. By default bindgen follows C++ naming to avoid
generating duplicate names.
With this option the following structs will be named as `foo`
and `bar` instead of `foo` and `foo_bar`.
```
struct foo {
struct bar {
} b;
};
```
In case of an unnamed definition we build the canonical name from
the inner most named definition. For example the following will
generate `baz__bindgen_ty_1`:
```
struct foo {
struct bar {
struct baz {
struct {
} u;
} z;
} b;
};
```
This option should be used only for C headers. It is needed in some
rare situations where user used another code generator that already
mangled nested definitions.
A real life example is [asn1c] with `-fcompound-names` option.
[asn1c]: https://github.com/vlm/asn1c
