| Age | Commit message (Collapse) | Author |
|---|
|
callback.
|
|
This reverts commit 6899c275ee0ab0687ec66c490ddd1a76f8223513.
The `proc_macro2` crate depends on rustc internal crates, which means that
`bindgen` would need to be run under `rustup`.
We can follow https://github.com/rust-lang/rust/issues/47931 to get updates on
when this issue might be resolved and we can update `quote` again.
Fixes #1248
|
|
|
|
|
|
Fixes #1185
|
|
codegen: Make forward declarations go through the more generic path.
Instead of special-casing.
This allows to use the normal flags to control what can be or not derived for
them.
Arguably deriving Copy / Clone is kind of busted for those, but changing this by
default broke tests (RefPtr<ForwardDeclaredType> stopped working for example).
So I think this is a good compromise.
Fixes #1238
|
|
ir: Choose the right mangling for destructors on all codepaths.
Fixes #1133.
|
|
Instead of special-casing.
This allows to use the normal flags to control what can be or not derived for
them.
Arguably deriving Copy / Clone is kind of busted for those, but changing this by
default broke tests (RefPtr<ForwardDeclaredType> stopped working for example).
So I think this is a good compromise.
Fixes #1238
|
|
Fixes #1133.
|
|
By looking through typedefs, we also catch more complex cases like the ones that
appear on Android's stdlib.
Fixes #946
|
|
|
|
Just use the repr name we generate, since we generate constants for that.
It's not worth trying to guess the actual type to use IMO.
Bindings lose a bit of portability I guess, but that's really a lost bet
already, so instead of special-casing bool and map constants, let's use a
consistent representation everywhere.
Fixes #1145
|
|
That's only undefined for enums with fields.
Fixes #1224
See also: https://botbot.me/mozilla/rustc/2018-01-19/?msg=95934948&page=2
|
|
I think that's right, and the previous behavior was just a bug.
Rejigger the tests that show this difference since they aren't testing this in
particular, and avoids adding more per-platform tests.
|
|
codegen: Be consistent about variadic signatures.
Fixes #1216.
|
|
Fixes #1216.
|
|
Make issue-816.h compatible with bindgen's 3-clause BSD license.
This fixes issue https://github.com/rust-lang-nursery/rust-bindgen/issues/1206.
|
|
Fixes #1197.
|
|
repr(C) on enums
r? @pepyakin or @emilio
|
|
If we don't, then eddyb's recent layout optimizations will do unexpected things
to them.
We also need to handle empty `enum`s without variants. When `repr(C)` is on a
Rust `enum`, it cannot be empty, so we need to add a dummy.
|
|
Enable Cargo features for quickchecking crate
Logic to enable/disable special casing (due to known issues #550, #684, and #1153) has been exposed as features in the `quickchecking` crate's Cargo.toml file and corresponding `cfg` attributes in the source.
In addition to adding Cargo features, this PR represents the following:
- Documentation in `bindgen`'s CONTRIBUTING.md that points to a new README.md located in the `quickchecking` crate's directory.
- The Debug trait was implemented for the `HeaderC` type. This enables failing property tests to be reported as C source code rather than a Rust data structure.
- The ArrayDimensionC type is now used in header generation for union, struct, and basic declarations.
Thanks for taking a look and for any feedback!
Closes #1169
r? @fitzgen
|
|
- Fixed misspelling introduced in CONTRIBUTING.md
- Remove `quickchecking -h` output from README.md
|
|
Logic to enable/disable special casing (due to known issues #550, #684, and #1153) has been exposed as features in the `quickchecking` crate's Cargo.toml file and corresponding `cfg` attributes in the source.
In addition to adding Cargo features, this PR represents the following:
- Documentation in `bindgen`'s CONTRIBUTING.md that points to a new README.md located in the `quickchecking` crate's directory.
- The Debug trait was implemented for the `HeaderC` type. This enables failing property tests to be reported as C source code rather than a Rust data structure.
- The ArrayDimensionC type is now used in header generation for union, struct, and basic declarations.
Thanks for taking a look and for any feedback!
Closes #1169
r? @fitzgen
|
|
|
|
Quickchecking crate CLI
Prior to this commit the quickchecking crate used for generating proprty tests for bindgen was a [lib] target and had configurations that required commenting/uncommenting code to enable/disable. This meant it was inconvienent/prohibitive to configure the property tests on a per-run basis. This commit reorganizes the `quickchecking` crate to provide both [lib] and [[bin]] targets in order to expose those configurations through a CLI.
The configurations that are exposed through the [[bin]] target's CLI are:
* Count/number of tests to run.
* Directory to provide fuzzed headers
* Generation range corresponding to the range quickcheck uses to
* generate arbitrary.
__Usage from the__ `tests/quickchecking` __directory__
```bash
quickchecking 0.2.0
Bindgen property tests with quickcheck. Generate random valid C code and pass it to the csmith/predicate.py script
USAGE:
quickchecking [OPTIONS]
FLAGS:
-h, --help Prints help information
-V, --version Prints version information
OPTIONS:
-c, --count <COUNT> Count / number of tests to run. Running a fuzzed header through the predicate.py script can
take a long time, especially if the generation range is large. Increase this number if you're
willing to wait a while. [default: 2]
-p, --path <PATH> Optional. Preserve generated headers for inspection, provide directory path for header
output. [default: None]
-r, --range <RANGE> Sets the range quickcheck uses during generation. Corresponds to things like arbitrary usize
and arbitrary vector length. This number doesn't have to grow much for that execution time to
increase significantly. [default: 32]
```
Because the actual work of running the property tests moved to the [[bin]]
target, rather than duplicate that code in the `quickchecking` crate's tests
directory, some actual (very basic) tests for the `quickchecking` crate were
added.
*Note: I'm not attached to any of the option flags, if there are better characters/words for any of the options I've exposed I'll be happy to revise!
Also, I'm not sure how palatable the "global singleton" is for managing context (output path) across tests in the `lib.rs` file. Very open to suggestions on how to manage that if it's not an acceptable approach.
Thanks for taking a look, looking forward to feedback!
Closes #1168
r? @fitzgen
|
|
Prior to this commit the quickchecking crate used for generating proprty
tests
for bindgen was a [lib] target and had configurations that required
commenting/uncommenting code to enable/disable. This meant it was
inconvienent/prohibitive to configure the property tests on a per-run
basis.
This commit reorganizes the `quickchecking` crate to provide both [lib]
and
[[bin]] targets in order to expose those configurations through a CLI.
The configurations that are exposed through the [[bin]] target's CLI
are:
* Count/number of tests to run.
* Directory to provide fuzzed headers
* Generation range corresponding to the range quickcheck uses to
* generate arbitrary.
__Usage from the__ `tests/quickchecking` __directory__
```bash
quickchecking 0.2.0
Bindgen property tests with quickcheck. Generate random valid C code and
pass it to the csmith/predicate.py script
USAGE:
quickchecking [OPTIONS]
FLAGS:
-h, --help Prints help information
-V, --version Prints version information
OPTIONS:
-c, --count <COUNT> Count / number of tests to run. Running a
fuzzed header through the predicate.py script can
take a long time, especially if the
generation range is large. Increase this number if you're
willing to wait a while. [default: 2]
-p, --path <PATH> Optional. Preserve generated headers for
inspection, provide directory path for header
output. [default: None]
-r, --range <RANGE> Sets the range quickcheck uses during
generation. Corresponds to things like arbitrary usize
and arbitrary vector length. This number
doesn't have to grow much for that execution time to
increase significantly. [default: 32]
```
Because the actual work of running the property tests moved to the
[[bin]]
target, rather than duplicate that code in the `quickchecking` crate's
tests
directory, some actual (very basic) tests for the `quickchecking` crate
were
added.
*Note: I'm not attached to any of the option flags, if there are better
characters/words for any of the options I've exposed I'll be happy to
revise!
Thanks for taking a look, looking forward to feedback!
Closes #1168
r? @fitzgen
|
|
|
|
Property testing with quickcheck
This PR represents an attempt to address issue #970. It also represents a portion of the meta issue for fuzzing #972.
The code base reflected here uses quickcheck to generate C headers that
include a variety of types including basic types, structs, unions,
function prototypes and function pointers. The headers generated by quickcheck
are passed to the `csmith-fuzzing/predicate.py` script. Examples of headers
generated by this iteration of the tooling can be viewed
[here](https://gist.github.com/snewt/03ce934f35c5b085807d2d5cf11d1d5c).
At the top of each header are two simple struct definitions,
`whitelistable` and `blacklistable`. Those types are present in the vector that
represents otherwise primitive types used to generate. They represent a naive
approach to exposing custom types without having to intuit generated type names like
`struct_21_8` though _any actual whitelisting logic isn't implemented
here_.
Test success is measured by the success of the
`csmith-fuzzing/predicate.py`
script. This means that for a test to pass the following must be true:
- bindgen doesn't panic
- the resulting bindings compile
- the resulting bindings layout tests pass
#### Usage
```bash
cd tests/property_test
cargo test
```
Some things I'm unsure of:
#### Where should this feature live?
At the moment it lives in `tests/property_test` but isn't run when
`cargo test` is invoked from bindgen's cargo manifest directory.
#### What's an acceptable ammount of time for these tests to take?
At this point, the source is genereated in ~1 second but the files are
large enough that it takes the `predicate.py` script ~30 seconds to run
through each one. In order for the tests to run in under a minute only 2 are
generated by quickcheck by default. This can be changed in the `test_bindgen`
function of the `tests/property_test/tests/fuzzed-c-headers.rs` file.
#### How do we expose the generated code for easy inspection?
For now the `run_predicate_script` function in the
`tests/property_test/tests/fuzzed-c-headers.rs` file contains a
commented block that will copy generated source in the `tests/property_test/tests`
directory. Should it be easier?
#### Special casing
There is some logic in the fuzzer that disallows 0 sized arrays because
tests will regulary fail due to issues documented in #684 and #1153. Should
this be special casing?
#### Does the fuzzer warrant its own crate?
After any iterations the reviewers are interested in required to make
this a functional testing tool, should/could the fuzzing library be made into
its own crate? I didn't move in that direction yet because having it all in one
place seemed like the best way to figure out what works an doesn't but I'm
interested in whether it might be useful as a standalone library.
#### What does it look like to expose more useful functionality?
I'm looking forward to feedback on how to make this a more useful tool
and one that provides the right configurability.
Thanks!
r? @fitzgen
|
|
- Remove `whitelistable` and `blacklistable` types.
- Rename test crate directory from `property_test` to `quickchecking`.
- Add new CI job that checks that this crate continues to build.
- Revise matching logic to be more idomatic.
- Phase out modular arithmetic in favor of `gen_range`.
- Incorporate `unreachable!` into match statements.
- Revise logic for accessing random element of vector, favor `choose`
over `nth`.
- Proper punctuation and capitalization in comments.
- Using actual structures rather than converting everything to strings
in order to leverage type system.
- Add `#![deny(missing_docs)]` and filled in documentation required for
the project to build again.
- Add special case logic so we don't generate structs with `long double`
fields as it will cause tests to fail unitl issue \#550 is resolved
Note on making sure we don't lose test cases we're interested in
preserving:
We're copying the directories `TempDir` makes so we get things like
this:
```
├── bindgen_prop.1WYe3F5HZU1c
│ └── prop_test.h
├── bindgen_prop.H4SLI1JX0jd8
│ └── prop_test.h
```
I'm not sure that `TempDir` makes any claims about uniqueness, so
collisions
probably aren't impossible. I'm up for any suggestions on a more
bulletproof
solution.
_Tasks not addressed by this PR:_
* TODO: Add `cargo features` logic to allow generating problematic code.
* TODO: Make a [bin] target with CLI to manage test settings.
* TODO: Whitelisting and opaque types.
* TODO: Generate bitfields, C++, I-bogus-codegen cases.
Figured this would be a good point to update the PR but if any of the
above TODO
items should be incorporated before moving forward I'm up for it!
Thanks for taking another look!
r? @fitzgen
|
|
Remove unnecessary ci jobs
And then in the process I noticed that we weren't running the layout tests for any of the libclang version-specific expectation files, so I also fixed that.
r? @emilio or @pepyakin
|
|
This adds a build.rs to generate
#[path="$FILE"]
mod $FILE_AS_IDENT;
for each $FILE in our libclang version-specific directories. We need to do this
to get those files' layout tests to run because cargo doesn't automatically pick
up tests in subdirectories.
|
|
...by using canonical_path rather than canonical_name.
Fixes #1125.
|
|
Support bitfield allocation units larger than 64 bits
Individual bitfields are still limited to at most 64 bits, but this restriction can be weakened when Rust supports `u128`.
This implements issue #816.
Usage notes:
* Since common code is added to each generated binding, a program which uses
more than one binding may need to work around the duplication by including
each binding in its own module.
* The values created by bitfield allocation unit constructors can be assigned
directly to the corresponding struct fields with no need for transmutation.
Implementation notes:
`__BindgenBitfieldUnit` represents a bitfield allocation unit using a `Storage`
type accessible as a slice of `u8`. The alignment of the unit is inherited from
an `Align` type by virtue of the field:
```
align: [Align; 0],
```
The position of this field in the struct is irrelevant.
It is assumed that the alignment of the `Storage` type is no larger than the
alignment of the `Align` type, which will be true if the `Storage` type is, for
example, an array of `u8`. This assumption is checked in a debug assertion.
Although the double underscore (__) prefix is reserved for implementations of
C++, there are precedents for this convention elsewhere in bindgen and so the
convention is adopted here too.
Acknowledgement:
Thanks to @fitzgen for an initial implementation of `__BindgenBitfieldUnit` and
code to integrate it into bindgen.
r? @emilio
|
|
a portion of the meta issue for fuzzing #972.
The code base reflected here uses quickcheck to generate C headers that
include a variety of types including basic types, structs, unions,
function
prototypes and function pointers. The headers generated by quickcheck
are
passed to the `csmith-fuzzing/predicate.py` script. Examples of headers
generated by this iteration of the tooling can be viewed
[here](https://gist.github.com/snewt/03ce934f35c5b085807d2d5cf11d1d5c).
At the top of each header are two simple struct definitions,
`whitelistable`
and `blacklistable`. Those types are present in the vector that
represents
otherwise primitive types used to generate. They represent a naive
approach to
exposing custom types without having to intuit generated type names like
`struct_21_8` though _any actual whitelisting logic isn't implemented
here_.
Test success is measured by the success of the
`csmith-fuzzing/predicate.py`
script. This means that for a test to pass the following must be true:
- bindgen doesn't panic
- the resulting bindings compile
- the resulting bindings layout tests pass
```bash
cd tests/property_test
cargo test
```
Some things I'm unsure of:
At the moment it lives in `tests/property_test` but isn't run when
`cargo test`
is invoked from bindgen's cargo manifest directory.
At this point, the source is genereated in ~1 second but the files are
large
enough that it takes the `predicate.py` script ~30 seconds to run
through each
one. In order for the tests to run in under a minute only 2 are
generated by
quickcheck by default. This can be changed in the `test_bindgen`
function of the
`tests/property_test/tests/fuzzed-c-headers.rs` file.
For now the `run_predicate_script` function in the
`tests/property_test/tests/fuzzed-c-headers.rs` file contains a
commented block
that will copy generated source in the `tests/property_test/tests`
directory.
Should it be easier?
There is some logic in the fuzzer that disallows 0 sized arrays because
tests
will regulary fail due to issues documented in #684 and #1153. Should
this be
special casing?
After any iterations the reviewers are interested in required to make
this
a functional testing tool, should/could the fuzzing library be made into
its own
crate? I didn't move in that direction yet because having it all in one
place
seemed like the best way to figure out what works an doesn't but I'm
interested
in whether it might be useful as a standalone library.
I'm looking forward to feedback on how to make this a more useful tool
and one
that provides the right configurability.
Thanks!
r? @fitzgen
|
|
Individual bitfields are still limited to at most 64 bits, but this
restriction can be weakened when Rust supports u128.
This implements issue #816.
Usage notes:
* Since common code is added to each generated binding, a program which uses
more than one binding may need to work around the duplication by including
each binding in its own module.
* The values created by bitfield allocation unit constructors can be assigned
directly to the corresponding struct fields with no need for transmutation.
Implementation notes:
__BindgenBitfieldUnit represents a bitfield allocation unit using a Storage
type accessible as a slice of u8. The alignment of the unit is inherited from
an Align type by virtue of the field:
align: [Align; 0],
The position of this field in the struct is irrelevant.
The alignment of the Storage type is intended to be no larger than the
alignment of the Align type, which will be true if the Storage type is, for
example, an array of u8.
Although the double underscore (__) prefix is reserved for implementations of
C++, there are precedents for this convention elsewhere in bindgen and so the
convention is adopted here too.
Acknowledgement:
Thanks to @fitzgen for an initial implementation of __BindgenBitfieldUnit and
code to integrate it into bindgen.
|
|
|
|
This fixes https://github.com/rust-lang-nursery/rust-bindgen/issues/954.
|
|
Instead of panicking when we see a bitfield that does not have a layout, return
an error up the stack. If we get an error when allocating bitfields into units,
then make the whole struct opaque.
Fixes #1140
|
|
...instead of the deprecated `hide_type`.
|
|
This is a bandaid for #537. It does *not* fix the underlying issue, which
requires `#[repr(packed = "N")]` support in Rust. However, it does make sure
that we don't generate type definitions with the wrong layout, or fail our
generated layout tests.
|
|
It isn't checking alignment at all; it's checking offsets.
|
|
|
|
According to the x86[-64] ABI spec: "Unnamed bit-fields’ types do not affect the
alignment of a structure or union". This makes sense: such bit-fields are only
used for padding, and we can't perform an un-aligned read of something we can't
read because we can't even name it.
Fixes #1076
|
|
Fixes #1118
|
|
|
|
Fixes #1113.
|
|
Simplify the rustfmt and write mechanism. Use rustfmt generated string to allow
writing to stdout or to rustfmt a file.
|
|
|
|
Tell `rustfmt` to shut up about long lines in comments in test expectations
|
|
|
