| Age | Commit message (Collapse) | Author |
|---|
|
This commit adds a Users Guide, built with [mdbook][] (the same tool used
by *The Rust Book*).
It moves all the user documentation from the README.md into the Users Guide. It
leaves the README.md as a splash page featuring an example of what `bindgen` is
and does, a link to the Users Guide, a link to the docs.rs/bindgen API reference
documentation, and a link to CONTRIBUTING.md.
It ensures that the Users Guide builds with `mdbook`, and all code snippets
within it build as doctests and pass, on every CI run.
Finally, it builds and uploads the Users Guide every time CI passes on the
master branch.
[mdbook]: https://github.com/azerupi/mdBook
|
|
r=emilio
Fix blacklisting and fix instantiations in the template analysis
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!
Fixes #662.
r? @emilio
|
|
OSX has the BSD mktemp which is subtly different from GNU's in uninteresting
ways.
|
|
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
|
|
Fix doc comments
I tried my best to understand the existing doc comments, but please verify that I did not change their intended meaning.
Also, I'm not sure if my local `rustfmt` is set up correctly, but running `cargo fmt` locally caused a lot of rust code to be changed, so I did not commit those changes.
|
|
|
|
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
|
|
Also resolve blacklisted instantiation's args through refs and aliases
r? @emilio
|
|
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.
|
|
Previously, the test-one.sh script hard coded common bindgen flags to run the
specified test with. Now, it parses the `// bindgen-flags:` comment in the test
header and uses those flags when running bindgen.
|
|
ir: consider all nested definitions inside structs to be inner types.
Fixes #643
|
|
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
|
|
More fixes for Stylo
See each commit message for details. https://github.com/servo/rust-bindgen/commit/bce13307645172be62e8895e82d9362f0c4e4fd6 is the big correctness fix for a bug we were hitting in stylo.
r? @emilio
|
|
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 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
|
