| Age | Commit message (Collapse) | Author |
|---|
|
ir: Support nested namespace specifiers.
Fixes #677
|
|
The previous behavior was that it would reconfigure the builder to generate
bindings to the last header `Builder::header` was invoked with. This was not
what people would expect: they expected it to generate bindings for all of the
headers, and were accidentally misconfiguring their builders.
This is a breaking change, but moves us inline with users' expectations.
|
|
|
|
Fixes #659
|
|
The template parameter usage analysis needs to see the template parameters'
definitions and have edges from any inner type to the parent in order to
propagate data flow through dependencies properly.
Fixes #674
|
|
|
|
For correctness, I now realize that we need to consider the full transitive
closure of whitelisted items, including blacklisted items that we would
otherwise not consider as whitelisted. We need this so that the data flow
propagates properly through dependencies that may or may not be blacklisted.
This means that tracing infrastructure needs to trace items regardless if they
are hidden or blacklisted. It is now the responsibility of consumers of a
traversal to filter out such items if they are unwanted. I did this by turning
the `ir::context::WhitelistedItems` type alias into a proper struct that
performs the filtering. This approach avoids changing the many callers of
whitelisted items traversal iteration.
Additionally, and equally importantly, I realized that the case of template
instantiations' template usages were subtly wrong. Before this commit, we only
considered a template argument used if it itself was a template parameter. This
breaks down in the face of template instantiations used as arguments to another
template instantiation. If the inner instantiation used a template parameter, we
would accidentally lose that usage. For example:
```c++
template <class T>
struct Foo {
// Direct usage of a template parameter T in an instantiation always worked.
Bar<T> member;
// While indirect usage of a template parameter nested within another
// instantiation did NOT previously work.
Bar< Qux<T> > another_member;
};
```
The solution is to take the union of each template arguments' template usages,
not the template arguments themselves but only if they were themselves a
template parameter. Obvious in retrospect!
|
|
ir: Try to get C++ manglings with the appropriate API first.
As pointed out in #653, clang 3.8 asserts when trying to mangle a C++
constructor or a destructor.
The following patch tries to use the `clang_Cursor_getCXXManglings` function
first.
This assumes that the last mangling we're interested in is the proper one,
which seems to be true looking at LLVM, and on trunk on my machine.
Fixes #653
|
|
codegen: Change forward-declared types to avoid collisions with functions.
Fixes #654
|
|
|
|
As pointed out in #653, clang 3.8 asserts when trying to mangle a C++
constructor or a destructor.
The following patch tries to use the `clang_Cursor_getCXXManglings` function
first.
This assumes that the last mangling we're interested in is the proper one, which
seems to be true looking at LLVM, and on trunk on my machine.
|
|
Fixes #654
|
|
When resolving a template argument in an instantiation of a blacklisted
template, we should resolve through type references and aliases so that we don't
accidentally lose template parameter usage information. Basically, this case
should have been in bce1330, but slipped through the cracks.
Fixes #645.
|
|
Fixes #643
|
|
ir: Ensure we check for typedefs of anonymous structs at the right time.
They appear later in the clang AST, so we need to check for them as a
special-case before flushing the new field.
|
|
They appear later in the clang AST, so we need to check for them as a
special-case before flushing the new field.
Fixes #639
|
|
These logs are pretty loud, so let's knock em down a log level.
|
|
Organizationally, it makes more sense.
|
|
The trait is all about accessing template parameters, and is also implemented
for things that are not template declarations or definitions, but do end up
using template parameters one way or another. The new name makes more sense.
|
|
It had some incorrectness where there was a difference between the abstract
`self_template_param_usage` and `template_param_usage` functions. In reality,
they are different cases of the same function. The comment was misleading in
that it implied that we run both on the same IR item, when in fact we will only
run one or the other. I've tried to make it more clear in the new version of the
comment.
|
|
The method was getting fairly large, and it is a little easier to read if we
break it down into smaller parts.
|
|
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 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.
|
|
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.
|
|
Use AsRef<str> rather than Into<String> because &&str (what you get
when iterating &[&str]) does not implement the latter.
|
|
|
|
|
|
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]
|
|
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
|
|
|
|
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
|
|
|
|
|
|
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.
|
|
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
|
|
|
|
|
|
|
|
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
|
