| Age | Commit message (Collapse) | Author |
|---|
|
remove `clap` dependency :tada:
update the book installation instructions
|
|
|
|
Make `BindgenOptions` clonable
|
|
|
|
|
|
|
|
This doesn't change behavior but makes the code make more sense.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
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
|
|
cargo clippy --fix --tests
cargo +nightly fmt
|
|
|
|
Closes #2206
|
|
Now that we require Clang 5.0, there is no way for this function to return
None.
|
|
|
|
|
|
|
|
Here we delete a workaround that is no longer needed.
|
|
|
|
|
|
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
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
These can happen in certain cases involving incomplete qualified dependent
types. To avoid looping forever, we need to check for them.
Closes #2085.
|
|
|
|
|
|
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.
|
|
Fixes #1977 as of rust-lang/rust#74060 is available since Rust 1.47
Fixes #2041.
Closes #2070.
|
|
Fixes #2067
|
|
|
|
Closes #2044
Fixes #2043
See https://github.com/rust-lang/rust-bindgen/issues/2043 for details.
|
|
|
