| Age | Commit message (Collapse) | Author |
|---|
|
Fixes #852
|
|
|
|
Useful for debugging when constraints go wrong.
|
|
There are lots of different ways that a type can end up being opaque, and it is
best to handle all the ways in one fell swoop, rather than check each different
ways (for example, if a struct has non-type template params, if a template
instantiation's template definition has them, etc...) for each different type
kind.
|
|
|
|
|
|
|
|
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.
|
|
analysis to be sound.
|
|
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 is some copy-paste from the template param usage analysis that we don't
need here. We already assume that blacklisted items are `derive(Debug)`able, and
this doesn't change that.
|
|
a fixed point
`ConstrainResult::Changed` is much more legible than `true`.
|
|
|
|
|
|
processing replacements
Because these operations mutate the IR graph, its better to be safe and double
check again. Don't worry -- these checks only happen on
`testing_only_extra_assertions` builds!
|
|
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.
|
|
Set insertion returns true if it was *not* already in the set. The assertion was
already correct, but the name was backwards.
Additionally, this removes a `format!` that is unnecessary.
|
|
It is obvious from the module that it is in that it is an analysis.
|
|
Because we can't put the apostrophe in "can't" in variables and type names, it
doesn't read as well as "cannot".
|
|
|
|
They used to live in the same module, and there was less distinction between
them, so they used to make more sense entangled with each other. Now that they
are in separate files, they need a little bit of disentangling.
|
|
|
|
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
|
|
Windows uses non-ascii and non-visual characters in mangled names T.T
|
|
|
|
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
|
|
For very large logs to stdout, this prevents deadlocks.
|
|
|
|
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
|
|
|
|
Rather than eagerly expanding multiple input headers into `-include <header>`
clang arguments, store them explicitly until we actually go to generate
bindings. Same deal for unsaved file contents.
|
|
|
|
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.
|
|
|
|
ir: Properly skip inline namespaces when building names.
Fixes #789
|
|
Fixes #789
|
|
After some discussion in #765 we do not think anymore this it can ever
be true.
|
|
|
|
|
|
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
|
