| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
This reverts commit 0bb7b9f1c4652f63f41eba4064b79c044fd3d955.
It turns out our CI stopped running test expectations in an earlier
regression (from d73507e; fix incoming) and so this pull request actually
introduced a bunch of failures when compiling the test expectations and running
their unit tests :(
|
|
Instead of specifying whether or not to use stable, specify the Rust
release to support (one of several stable/beta releases or nightly).
The --unstable-rust option is still accepted and implies nightly.
The definitions of `RustTarget` and `RustFeatures` are created with
macros.
For each test that uses unions, there is a version that uses the latest
stable release and stable 1.0.
|
|
Fix regression of derive default analysis.
Also fix opaque handing exposed by the above fix.
|
|
|
|
|
|
Can derive default analysis
r? @fitzgen
|
|
|
|
|
|
|
|
When there is large enough alignment that we might generate padding which has
more members that `RUST_DERIVE_IN_ARRAY_LIMIT`, we can break our ability to
derive traits. This commit solves this issue conservatively: there are cases
where we leave a derive on the table, because in order to know that we could add
that derive, we would need to compute padding before we determine whether we can
derive.
Fixes #648
|
|
Fixes #852
|
|
|
|
And also not just fields, but also base members.
|
|
|
|
|
|
debug analysis.
We have a special-case for them in codegen to generate a blob, that can derive
debug.
This is a regression from #824, and hit stylo.
|
|
whitelisted_items() for code generation.
This standardizes the behavior change at #834, but without regressions.
I've added a few more tests for #833 here.
|
|
|
|
Use fully disambiguated name instead of a number for layout tests (fixes #394)
These numbers cause tons of churn in the diffs for checked in bindings.
r? @fitzgen
|
|
|
|
This makes only generating certain kinds of items more robust, since we don't
need to keep checking whether codegen is enabled for different kinds of items
all over the place, and can do it the once. It should also reduce the number of
items we have to consider in our various analyses for which we don't ultimately
care about the answer.
Fixes #826
|
|
Implement `IsOpaque` for `CompInfo`
This allows us to properly detect structs that should be treated as opaque due to their non-type template paramaters, which in turn lets us correctly codegen template aliases to such things.
Fixes #820
r? @emilio
|
|
This allows us to properly detect structs that should be treated as opaque due
to their non-type template paramaters, which in turn lets us correctly codegen
template aliases to such things.
Fixes #820
|
|
|
|
|
|
|
|
Preserve comments when dumping preprocessed input headers
It should be really easy to generate standalone, isolated test cases for bindgen bugs now \o/
See each commit for further details.
r? @emilio
|
|
|
|
The -C flag tells Clang's preprocessor not to strip comments, but unfortunately
Clang will only accept it when dumping the preprocessed file to stdout, which is
the -E flag. This means that we need to capture the child process's stdout and
then copy it to a file ourselves now.
|
|
This is useful when debugging bindgen, using C-Reduce on an input to bindgen, or
for constructing portable test cases when filing issues against bindgen.
Fixes #811
|
|
This makes tracing opaque types' edges match what we codegen for opaque
types. Although we still generate constructors, methods, etc for opaque
types (just not fields and base members) we were not tracing them.
Fixes #807
|
|
This commit moves comment processing to a central place (well, two, because of
field docs, but that's fine).
Also, it makes comments indentation aware, so multiline comments don't appear
garbled.
Finally, it also fixes an out-of-bounds panic when processing an empty multiline
comment.
|
|
Fixes #801
|
|
Intelligently convert C/C++ comments to Rust
With this change, we can correctly parse C++ block comments.
```cpp
/**
* Does a thing
*
* More documentation. This test does something
* useful.
*/
```
into
```rust
/// Does a thing
///
/// More documentation. This test does something
/// useful.
```
Fixes servo/rust-bindgen#426.
|
|
With this change, we can correctly parse C++ block comments.
```
/**
* Does a thing
*
* More documentation. This test does something
* useful.
*/
```
into
```
/// Does a thing
///
/// More documentation. This test does something
/// useful.
```
Fixes servo/rust-bindgen#426.
|
|
Automatically detect libclang version when testing
Automatically detect libclang version when testing and use approppriate
expectation files.
Ref to issue #794.
|
|
Automatically detect libclang version when testing and use approppriate
expectation files. Ref issue #794.
|
|
No system includes in test headers
See each commit message.
Disallowing *system* includes and not *all* includes because we have one local include in `extern.hpp`, and local includes will at least be consistent/reproducible.
r? @emilio
|
|
Convenience to help developers catch this earlier, rather than only after
pushing a pull request.
|
|
Fixes #789
|
|
On Mac OS where egrep is != GNU grep, the script fails with
~~~
egrep: repetition-operator operand invalid
ERROR: no files found with pattern "virtual_inheritance"
~~~~
The `$pattern` is supposed to be a substring in the test name to run.
The leading and trailing stars are wrong, since egrep takes a
regular expression, not a glob.
|
|
|
|
If a template has a specialization that bindgen doesn't understand, it can be
helpful to mark it as opaque and continue making forward progress in the
meantime. This is something we need in the SpiderMonkey bindings.
|
|
Feature 699 constified enum module
This is a work in progress for issue #699 that adds the `--constified-enum-module` option to bindgen.
@emilio, could you give me some guidance on fixing the uses of the enum variant types? In the example below, `foo` should be replaced with `foo::Type`. I'm not sure of the proper way to rename `Item`s after the structures have been defined. My initial thought was to redefine the `CodeGenerator` trait to take a mutable reference to `item`, but that will not work because of the borrow checker. Thoughts?
Todo:
- [x] put constified enum variants in a `mod`
- [x] ensure references to constified enum `foo` are changed to `foo::Type`
- [x] handle `typedef` enums
-----
Given the input header `tests/headers/constify-module-enums.h`:
~~~c
// bindgen-flags: --constified-enum-module foo
enum foo {
THIS,
SHOULD_BE,
A_CONSTANT,
};
struct bar {
enum foo this_should_work;
};
~~~
`$ cargo run -- tests/headers/constify-module-enums.h --constified-enum-module foo --no-layout-tests` will output:
~~~rust
/* automatically generated by rust-bindgen */
pub mod foo {
pub type Type = ::std::os::raw::c_uint;
pub const THIS: Type = 0;
pub const SHOULD_BE: Type = 1;
pub const A_CONSTANT: Type = 2;
}
#[repr(C)]
#[derive(Debug, Copy)]
pub struct bar {
pub this_should_work: foo,
}
impl Clone for bar {
fn clone(&self) -> Self { *self }
}
~~~
|
|
Used suggested code from @emilio and also added a test for an alias to
an anonymous enum.
|
|
Ensure that every item is in some module's children list
Previously, if an item's parent was not a module (eg a nested class definition whose parent it the outer class definition) and the parent was not whitelisted but the item was transitively whitelisted, then we could generate uses of the item without emitting any definition for it. This could happen because we were relying on the outer type calling for code generation on its inner types, but that relies on us doing code generation for the outer type, which won't happen if the outer type is not whitelisted.
This commit avoids this gotcha by ensuring that all items end up in a module's children list, and so will be code generated even if their parent is not whitelisted.
This does have the downside of changing the relative order of some of the emitted code, and so this has a big diff (as will the next bindgen update for downstream dependencies) but I actually think the newer order makes more sense, for what that is worth.
Fixes #769
r? @emilio
|
