| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
This deprecates `Builder::hide_type`.
Related to #984.
- [x] Add Builder::blacklist_type, that does the same thing as hide_type
- [x] Mark Builder::hide_type as #[deprecated = "Use blacklist_type instead"]
- [x] Make hide_type delegate to blacklist_type
- [x] Rename the BindgenOptions::hidden_types member to BindgenOptions::blacklisted_types
- [x] Rename ir::context::BindgenContext::hidden_by_name to blacklisted_by_name
- [x] Rename ir::item::Item::is_hidden to is_blacklisted
|
|
Also simplifies the logic that determines which enum variation gets chosen.
|
|
The `syntex` crate is unmaintained. It is slow to build, and additionally it
requires that we pre-process `src/codegen/mod.rs` before we build the `bindgen`
crate.
The `quote` crate provides similar quasi-quoting functionality, is maintained,
and builds faster. It doesn't have a typed API or builders, however; it only
deals with tokens.
Before this commit:
```
$ cargo clean; cargo build
<snip>
Finished dev [unoptimized + debuginfo] target(s) in 98.75 secs
```
After this commit:
```
$ cargo clean; cargo build
<snip>
Finished dev [unoptimized + debuginfo] target(s) in 46.26 secs
```
Build time is cut in half! But what about run time?
Before this commit:
```
Generated Stylo bindings in: Duration { secs: 3, nanos: 521105668 }
```
After this commit:
```
Generated Stylo bindings in: Duration { secs: 3, nanos: 548797242 }
```
So it appears to be about 20ms slower at generating Stylo bindings, but I
suspect this is well within the noise.
Finally, this also lets us remove that nasty `mem::transmute` inside
`bindgen::ir::BindgenContext::gen` that was used for the old `syntex`
context. Now `BindgenContext` doesn't have a lifetime parameter either. This
should make it easier to revisit doing our analyses in parallel with `rayon`,
since that context was one of the things that made it hard for `BindgenContext`
to implement `Sync`.
Fixes #925
|
|
|
|
initial timer branch commit
added time_phases builder parameter
create timers for BindgenContex analyses, codegen
time parse
added docstrings
added fitzgens suggestions
add --time-phases to bindgen::Builder::command_line_flags
|
|
Avoid generating fields/methods for opaque objects
WIP fix for issue #929
With libclang 4, passes all tests on my machine except `dump_preprocessed_input`, but that fails on the master branch as well
|
|
|
|
|
|
Thanks @fitzgen for the detailed instructions.
Fixes #928.
|
|
|
|
Also renames a bunch of other things referring to named types to refer to type
parameters.
Fixes #915
|
|
|
|
|
|
This fix creates a new private field with the required aligned size. This new
private field ensures that the union has the required size.
|
|
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 and 1.0.
This also fixes the bug where unions were generated with non-Copy
fields.
|
|
Implements Debug trait for types which do not support derive Debug
For types that do not support derive Debug be implemented automatically by rust,
we know can generate implementations of the Debug trait. This code generation is
hidden behind the '--force-derive-debug' command-line flag.
Should solve: #875
Sorry for the extra noise in lib.rs, codegen/mod.rs etc, that was rustfmt.
|
|
For types that do not support derive Debug be implemented automatically by rust,
we know can generate implementations of the Debug trait. This code generation is
hidden behind the '--force-derive-debug' command-line flag.
|
|
|
|
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.
|
|
|
|
|
|
Similar to `HasVtable::Extra`, it is no longer needed.
|
|
s/servo/rust-lang-nursery/ \o/
|
|
Fixes #852
|
|
|
|
|
|
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
|
|
We used to do this traversal all the time, but we can do it the one time, after
we finish constructing the IR graph and before we begin computing any of our
analyses.
|
|
|
|
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
|
|
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
|
|
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 }
}
~~~
|
|
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
|
|
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.
Fixes #769
|
|
... Which is what Firefox uses right now.
|
|
And also its trait methods `is_named` and `as_named` into `is_template_param`
and `as_template_param` respectively.
These new names better reflect what the trait is about.
|
|
|
|
Like the ones seen in https://bugzilla.mozilla.org/show_bug.cgi?id=1365254#c22
|
|
Fixes #734
|
|
|
|
Fixes #755
|
|
|
