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.
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.
```
Fixesservo/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.
```
Fixesservo/rust-bindgen#426.
Automatically detect libclang version when testing
Automatically detect libclang version when testing and use approppriate
expectation files.
Ref to 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
There is no guarantee that the system running the tests has the header file, let
alone the same version of it that you have. Any test with such an include
directive won't reliably produce the consistent bindings across systems.
Minimal test cases don't have `#include`s
The inclusion of an `#include` means that the test case
* is not minimal, and
* is harder to reproduce the bug with, since not everyone has the same headers (or versions of headers) on their system.
r? @emilio
The inclusion of an `#include` means that the test case
* is not minimal, and
* is harder to reproduce the bug with, since not everyone has the same headers (or versions of headers) on their system.
Fix tests/test-one.sh.
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.
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.
Drop llvm@3.9 versioning for homebrew.
Homebrew now defaults to llvm 4.0.x so there's no need to specify a specific version to get compatibility, unless we specifically want people using 3.9.
Fix iOS mangling
Hi,
We had a regression on a project that target iOS while upgrading bindgen from `0.25.3` to `0.25.4`.
After a long investigation it appeared that iOS need also a mangling hack. I managed to make a patch and successfully test it.
Thanks a lot for all your work.
Cheers
Allow marking specific template instantiations as opaque
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.
r? @emilio
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
This commit adds assertions that run when the "testing_only_extra_assertions"
feature is enabled, which make sure that every single item we parse is a child
of some ancestor module.
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
Before this commit, test-one.sh was unusable with tests/headers/template.hpp
because there were too many things with "template.hpp" as a suffix. This allows
us to specify "/template.hpp" to run the test.
Rename `AsNamed` to `AsTemplateParam`
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.
r? @emilio
switch defaults from generating unstable Rust to generating stable Rust
As said in the issue:
- changing the Builder::no_unstable_rust method to the Builder::unstable_rust method
- changing the --no-unstable-rust flag to a --unstable-rust flag in src/options.rs
- changing bindgen-flags header in the test headers to remove the --no-unstable-rust flag
- removing --no-unstable-rust flag in ./test/test-one.sh
Fixes#757
r? @fitzgen
- changing the Builder::no_unstable_rust method to the Builder::unstable_rust method
- changing the --no-unstable-rust flag to a --unstable-rust flag in src/options.rs
- changing bindgen-flags header in the test headers to remove the --no-unstable-rust flag
Fixes#757
