| 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.
|
|
|
|
|
|
|
|
GitHub issue 422 was fixed but needs a test.
https://github.com/rust-lang/rust-bindgen/issues/422
Signed-off-by: Amanjeev Sethi <aj@amanjeev.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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>
|
|
|
|
Add declarations for 'await' and 'async' variables to keywords.h
and update the expectations in keywords.rs.
|
|
Using the canonical type fixes this but changes the output of some tests
(in particular, pointer to typedefs now point to the underlying type).
So do this only in known-bad cases.
Fixes #2244
|
|
Closes #2206
|
|
this includes comments and must_use annotations
|
|
This is due to differences in representation of `signed long` and `unsigned long`
on most Linux-based systems and Windows (`64` vs. `32` bits)
|
|
|
|
This should have been added in #2155 but was missed then.
|
|
|
|
* Updated tests/expectations/Cargo.toml to use 2018 rust.
* Added Debug and Copy to objective-c structs.
* Fixed lifetimes in objective-c trait templates.
* Fixed imports for objective-c expectations tests.
|
|
|
|
|
|
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
|
|
Constant and static declaration have a 'static live time by default,
that is already elided since 1.17.
Clippy complains on this kind of strings that are present in the
generated code.
This patch remove the 'static live time for those strings when rustc >
1.17 via a new added RustFeature.
Fix #1612
Signed-off-by: Alberto Planas <aplanas@suse.com>
|
|
|
|
This previously produced a type alias which referred to itself,
which was clearly wrong and resulted in downstream code recursing
infinitely.
The problem case (per bug #2102) is:
template <typename> class B{};
template <typename c> class C {
public:
using U = B<c>;
};
class A : C<A> {
U u;
};
As far as I can tell, we parse clang's definition of B<A>; that leads
us to parse A; to find it has a field U which turns out to be of type
B<A>. And so we hit the line in item.rs which says:
debug!("Avoiding recursion parsing type: {:?}", ty);
and bail out, returning the original item ID: hence, a self-
referential typedef is created.
The 'fix' in this PR creates an opaque type in this case instead,
to avoid later infinite loops. It would be preferable to avoid this
situation in the first place, but presumably that would require
us to split the parsing phase into two:
1) types
2) fields within those types.
Fixes #2102.
|
|
The --explicit-padding flag would make bindgen try to add tail padding
to rust unions, by adding up the size of all the union fields and
subtracting from the size of the union as given by clang. The total size
of a union's fields is always larger than the union, so the subtraction
underflowed and bindgen produced padding fields larger than addressable
RAM.
|
|
These can happen in certain cases involving incomplete qualified dependent
types. To avoid looping forever, we need to check for them.
Closes #2085.
|
|
|
|
derives, or prevent deriving traits
Fixes #2076
|
|
|
|
|
|
complete type.
It might not if we had to avoid recursion when processing types. Detect that
case and bail out. This bug was being masked by the fact that we didn't always
find definitions for the recursion check and so it didn't trigger, but now that
this check is more reliable we have to be careful in more places.
The test case was reduced from the GCC STL allocator definition.
|
|
In some esoteric cases involving nested templates,
`ty.declaration().definition()` isn't enough to find the definition: we need
`ty.canonical_type().declaration().definition()` instead.
Closes #2078.
|
|
use the Default trait.
Fixes #2082
|
|
Fixes #1977 as of rust-lang/rust#74060 is available since Rust 1.47
Fixes #2041.
Closes #2070.
|
|
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.
|
|
Fixes #2067
|
|
|
|
Closes #2044
Fixes #2043
See https://github.com/rust-lang/rust-bindgen/issues/2043 for details.
|
|
Closes #2045.
Fixes #1252.
|
|
This fixes a panic with the following header:
template<typename T>
struct Foo {};
template<typename T>
Foo<T> foo{};
void f() {
struct Bar {
Bar() {}
};
foo<Bar>;
}
Because we don't parse the insides of function bodies, code like this could
cause us to parse a type (here, `Bar`) that we didn't see in our initial pass,
which can cause subtle problems.
Closes #2036.
|
|
|
