| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
clang: Fix most of the clang 5.0 regressions in our tests.
|
|
|
|
Add a `Builder::header_contents` method to allow passing source code as a string to a Builder
Currently the Builder API requires input as header files on disk. This allows
passing C source directly to clang using the existing UnsavedFile struct.
I'm going to take a shot at implementing a webapp that lets users paste in C source and get the bindgen output. It would make life easier if I didn't have to write the source out to a temp file. This patch allows passing the source in as a `&str`.
I wasn't quite sure where to put the new test, but it seems to work in tests.rs.
|
|
string to a Builder
Currently the Builder API requires input as header files on disk. This allows
passing C source directly to clang using the existing UnsavedFile struct.
|
|
ir: Prefer the enum definition instead of the declaration when looking for variants.
Fixes #599
|
|
variants.
|
|
```
warning: found non-foreign-function-safe member in struct marked #[repr(C)]: found zero-size struct in foreign module, consider adding a member to this struct
```
|
