| Age | Commit message (Collapse) | Author |
|---|
|
remove `clap` dependency :tada:
update the book installation instructions
|
|
|
|
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.
|
|
|
|
|
|
|
|
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>
|
|
Both `Arg::value_name` and `Arg::number_of_values` imply
`Arg::takes_value`, so those calls are just noise.
|
|
--verbose
Fixes #2138
|
|
|
|
|
|
|
|
Update Item to hold a `clang::SourceLocation` and use this to allow
blocklisting based on filename.
The existing code has a special case that always maps <stdint.h> integer
types to corresponding Rust integer types, even if the C types are
blocklisted. To match this special case behaviour, also treat these
C <stdint.h> types as being eligible for derived Copy/Clone/Debug
traits.
Fixes #2096
|
|
|
|
|
|
|
|
If a struct needs to be serialized in its native format (padding bytes
and all), for example writing it to a file or sending it on the network,
then explicit padding fields are necessary, as anything reading the
padding bytes of a struct may lead to Undefined Behavior.
|
|
Closes #2045.
Fixes #1252.
|
|
Needed to auto-bindgen with a ninja build without the build graph
going stale.
|
|
|
|
Fixes #430
|
|
This reverts commit 7286c815f80b14c0ee77773387434da40f511b42, because it
was not intended to be merged after all, see
https://github.com/rust-lang/rust-bindgen/pull/2003#issuecomment-796160427.
|
|
Fixes #1454
|
|
For the commandline arguments I added undocumented aliases to old flags,
to stay backwards compatible.
|
|
|
|
Add a `--fit-macro-constant-types` option to make bindgen try to fit
macro integer constants into types smaller than u32/i32.
Useful especially when dealing with 8/16-bit architectures.
Closes #1945
|
|
This makes command_line_args properly return them, instead of dropping
them on the floor.
|
|
Sometimes, we need customize the implement of `Default` for certain types,
In these cases, the `nodefault` annotation can be used to prevent bindgen
to autoderive the `Default` traits for a type.
|
|
Closes #1541.
Closes #1846.
Co-authored-by: Michael-F-Bryan <michaelfbryan@gmail.com>
|
|
* --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"
|
|
|
|
|
|
Allow to use the given prefix for the anon fields instead of `__bindgen_anon_`.
|
|
|
|
|
|
One more thing that we can configure from the command line.
|
|
|
|
|
|
This adds an enum style similar to the existing bitfield style, without
the bitwise operator impls.
Closes: #1669
|
|
|
|
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
|
|
|
|
|
|
Fixes #1598
|
|
Implements the feature discussed in
https://github.com/rust-lang/rust-bindgen/issues/1554.
|
|
|
|
|
|
And don't do it conditionally on the presence of --target. We pass the clang
arguments to clang-sys now, so it doesn't get the wrong path.
|
|
|
|
Given it was a considerable performance hit under some workloads.
Closes #1465.
|
