| Age | Commit message (Collapse) | Author |
|---|
|
In stylo bindings generation, we were hitting bugs where the analysis saw a
template type parameter behind a type ref to a type alias, and this was then
used as an argument to a template instantiation. Because of the indirection, the
analysis got confused and ignored the template argument because it was "not" a
named template type, and therefore we didn't care about its usage.
This commit makes sure that we keep resolving through type references and
aliases to find the inner named template type parameter to add to the current
item's usage set.
Fixes #638.
|
|
This commit makes the test-one.sh script log the input header as well as the
emitted bindings to stdout.
|
|
This commit adds a bunch of debug logging to the template type parameters
analysis. I've essentially adding this same code and then never committed it,
like three or four different times. Because I keep re-writing it, I think it is
worth keeping around in a more permanent fashion.
|
|
We have a couple knobs to turn for item resolution, such as whether we keep
going through type references and type aliases. It makes sense to have a single,
easy place to configure these knobs.
|
|
Finish fixing blacklisting + template analysis
This is a follow up to c8a206a, and the support for blacklisting in the named template parameter usage analysis. This ensures that ever item we ever call `constrain` on has an entry in `used` for the set of template parameters it uses. Additionally, it adds extra assertions to enforce the invariant.
We cannot completely avoid analyzing blacklisted items because we want to consider all of a blacklisted template's parameters as used. This is why we ensure that blacklisted items have a used template parameter set rather than ensuring that blacklisted items never end up in the worklist.
This fixes the panic I saw in https://github.com/servo/servo/pull/16392, but there are still issues leftover in the resulting bindings that I am tracking down.
r? @emilio
|
|
This is a follow up to c8a206a, and the support for blacklisting in the named
template parameter usage analysis. This ensures that ever item we ever call
`constrain` on has an entry in `used` for the set of template parameters it
uses. Additionally, it adds extra assertions to enforce the invariant.
We cannot completely avoid analyzing blacklisted items because we want to
consider all of a blacklisted template's parameters as used. This is why we
ensure that blacklisted items have a used template parameter set rather than
ensuring that blacklisted items never end up in the worklist.
|
|
...and trailing whitespace.
|
|
build: Don't always expect a tests/headers directory.
It may not exist after packaging. This should unblock publishing bindgen.
|
|
It may not exist after packaging. This should unblock publishing bindgen.
|
|
Add Builder::clang_args (plural)
Use `AsRef<str>` rather than `Into<String>` because `&&str` (what you get when iterating `&[&str]`) does not implement the latter.
|
|
Use AsRef<str> rather than Into<String> because &&str (what you get
when iterating &[&str]) does not implement the latter.
|
|
Option to avoid generating layout tests
as discussed in #424
|
|
|
|
|
|
Issue #548 : Added command line flag generation method to Builder
1. Added new method `command_line_flags` to `Builder` to generate
list of command line arguments supplied.[file: src/lib.rs]
2. Added new method `get_set` and `get_items` method to `RegexSet`
to return immutable reference to it's fields.[file: src/regex_set.rs]
3. Added simple test case for `command_line_flags` method.[file: src/lib.rs]
|
|
1. Added new method `command_line_flags` to `Builder` to generate
list of command line arguments supplied.[file: src/lib.rs]
2. Added new method `get_set` and `get_items` method to `RegexSet`
to return immutable reference to it's fields.[file: src/regex_set.rs]
3. Added simple test case for `command_line_flags` method.[file: src/lib.rs]
|
|
Add a Stylo bindings sanity test
This commit adds a sanity test that we can generate bindings for Stylo without
any errors. I tried to make this a `#[bench]` but each iteration takes 36
seconds on my machine, which made the `#[bench]` take *way* too long. Instead,
there is a commented out `panic!` that can be uncommented to get a log of how
long it took.
r? @emilio
|
|
This commit adds a sanity test that we can generate bindings for Stylo without
any errors. I tried to make this a `#[bench]` but each iteration takes 36
seconds on my machine, which made the `#[bench]` take *way* too long. Instead,
there is a commented out `panic!` that can be uncommented to get a log of how
long it took.
|
|
Bump to version 0.23.0
Glancing through the git log it looks like a public API or two was renamed, and what with the template refactoring work, it seems like emitted bindings will be different enough that a breaking version bump is called for.
r? @emilio
|
|
|
|
fitzgen:issue-584-stylo-blacklisting-in-template-analysis, r=emilio
Correctly handle blacklisted items in the template analysis
The template analysis operates on whitelisted items, and uses our tracing
infrastructure to move between them. Usually, that means we can only reach other
whitelisted items by tracing, because the set of whitelisted items is the
transitive closure of all the items explicitly whitelisted. The exception is
when some type is explicitly blacklisted. It could still be reachable via
tracing from a whitelisted item, but is not considered whitelisted due to the
blacklisting.
The easy fix is to run the template analysis on the whole IR graph rather than
just the whitelisted set. This is an approximately one line change in the
analysis, however is not desirable due to performance concerns. The whole point
of whitelisting is that there may be *many* types in a header, but only a *few*
the user cares about, or there might be types that aren't explicitly needed and
that are too complicated for bindgen to handle generally (often in
`<type_traits>`). In these situations, we don't want to waste cycles or even
confuse ourselves by considering such types!
Instead, we keep the whitelisted item set around and check by hand whether any
given item is in it during the template type parameter analysis.
Additionally, we make the decision that blacklisted template definitions use all
of their type parameters. This seems like a reasonable choice because the type
will likely be ported to Rust manually by the bindgen user, and they will be
looking at the C++ definition with all of its type parameters. They can always
insert `PhantomData`s manually, so it also gives the most flexibility.
Fixes #584
r? @emilio
|
|
The template analysis operates on whitelisted items, and uses our tracing
infrastructure to move between them. Usually, that means we can only reach other
whitelisted items by tracing, because the set of whitelisted items is the
transitive closure of all the items explicitly whitelisted. The exception is
when some type is explicitly blacklisted. It could still be reachable via
tracing from a whitelisted item, but is not considered whitelisted due to the
blacklisting.
The easy fix is to run the template analysis on the whole IR graph rather than
just the whitelisted set. This is an approximately one line change in the
analysis, however is not desirable due to performance concerns. The whole point
of whitelisting is that there may be *many* types in a header, but only a *few*
the user cares about, or there might be types that aren't explicitly needed and
that are too complicated for bindgen to handle generally (often in
`<type_traits>`). In these situations, we don't want to waste cycles or even
confuse ourselves by considering such types!
Instead, we keep the whitelisted item set around and check by hand whether any
given item is in it during the template type parameter analysis.
Additionally, we make the decision that blacklisted template definitions use all
of their type parameters. This seems like a reasonable choice because the type
will likely be ported to Rust manually by the bindgen user, and they will be
looking at the C++ definition with all of its type parameters. They can always
insert `PhantomData`s manually, so it also gives the most flexibility.
Fixes #584
|
|
update dependencies
no special reason, just making myself useful (hopefully!)
|
|
|
|
Don't generate accessor methods for large bitfields
This fixes #570, by not generating accessor methods for large methods.
|
|
Extra assertions and cargo features
* Clean up testing-only cargo features
This commit ensures that all of the cargo features we have that only exist for
CI/testing purposes, and aren't for external consumption, have a "testing_only_"
prefix.
* Define extra assertion macros
This commit defines a new set of assertion macros that are only checked in
testing/CI when the `testing_only_extra_assertions` feature is enabled. This
makes it so that *users* of bindgen that happen to be making a debug build don't
enable all these extra and expensive assertions.
Additionally, this removes the `testing_only_assert_no_dangling_items` feature,
and runs the assertions that were previously gated on that feature when the new
`testing_only_extra_assertions` feature is enabled.
r? @emilio
|
|
Provide better diagnostics for assertions in the template analysis
This replaces various `unwrap` calls with `expect` calls that have better diagnostic messages if/when they fail.
Doing this as part of the investigation into why the analysis is failing when producing bindings for stylo.
r? @emilio
|
|
|
|
|
|
This replaces various `unwrap` calls with `expect` calls that have better
diagnostic messages if/when they fail.
|
|
This commit defines a new set of assertion macros that are only checked in
testing/CI when the `testing_only_extra_assertions` feature is enabled. This
makes it so that *users* of bindgen that happen to be making a debug build don't
enable all these extra and expensive assertions.
Additionally, this removes the `testing_only_assert_no_dangling_items` feature,
and runs the assertions that were previously gated on that feature when the new
`testing_only_extra_assertions` feature is enabled.
|
|
This commit ensures that all of the cargo features we have that only exist for
CI/testing purposes, and aren't for external consumption, have a "testing_only_"
prefix.
|
|
Don't build documentation for the binary, just the lib
This enables one to locally do
$ cargo doc
and get library level documentation. Without the changes, cargo doesn't know whether to build docs for the binary or library, and so instead it gives an error and stops.
r? @emilio
|
|
This enables one to locally do
$ cargo doc
and get library level documentation. Without the changes, cargo doesn't know
whether to build docs for the binary or library, and so instead it gives an
error and stops.
|
|
Add a test explicitly for default type parameters
This is exercised in other tests, but in a round about fashion. It is nice to have a test that explicitly exercises default type parameters, without any cruft.
r? @emilio
|
|
This is exercised in other tests, but in a round about fashion. It is nice to
have a test that explicitly exercises default type parameters, without any
cruft.
|
|
Generalize template instantiation fallibility
Return `None` whenever we can't find a template definition, not only when the
template is a builtin.
Hitting this in other tests with libclang 4
r? @emilio or @upsuper
|
|
But only if the type is not a builtin type. If it is a builtin type, then it's
expected that we won't have a definition.
|
|
Return `None` whenever we can't find a template definition, not only when the
template is a builtin.
|
|
Handle when we can't instantiate templates because we can't find a template definition
https://github.com/servo/rust-bindgen/pull/594 + my review commetn about using opaque types
|
|
|
|
This should fix #584.
|
|
Fall back to opaque types rather than panicking on parse failure
Getting closer to figuring out some of the other template related issues in clang 4.0, but not quite ready to land them yet. Figure this should probably land in the meantime. This is just a better fallback in the face of the unknown for panics that we've had reports of in the wild, but which I haven't had time to creduce.
r? @emilio
|
|
|
|
Treat char as c_char
Per #603.
This still leaves `bindgen` having to make a call as to what to say when asked whether `Char` `is_signed()`. I've opted just to leave this as `true`, on the grounds that:
* I don't currently understand an example where it matters
* I suspect that if there are cases where it matters, then it shouldn't!
* Because by definition, use of unadorned `char` in the original header says that it doesn't care about signedness
* (signed is the common case, so that's a more sensible guess than unsigned)
|
|
|
|
|
|
ir: Handle char in a more cross-platform way when possible.
This should address #603, and supersede #609
|
|
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
|
|
Destructor codegen
Based on #542, and on top of #606, with a bunch more tests and fixes.
|
