| Age | Commit message (Collapse) | Author |
|---|
|
Previously, if an item's parent was not a module (eg a nested class definition
whose parent it the outer class definition) and the parent was not whitelisted
but the item was transitively whitelisted, then we could generate uses of the
item without emitting any definition for it. This could happen because we were
relying on the outer type calling for code generation on its inner types, but
that relies on us doing code generation for the outer type, which won't happen
if the outer type is not whitelisted.
This commit avoids this gotcha by ensuring that all items end up in a module's
children list, and so will be code generated even if their parent is not
whitelisted.
Fixes #769
|
|
... Which is what Firefox uses right now.
|
|
Before this commit, test-one.sh was unusable with tests/headers/template.hpp
because there were too many things with "template.hpp" as a suffix. This allows
us to specify "/template.hpp" to run the test.
|
|
switch defaults from generating unstable Rust to generating stable Rust
As said in the issue:
- changing the Builder::no_unstable_rust method to the Builder::unstable_rust method
- changing the --no-unstable-rust flag to a --unstable-rust flag in src/options.rs
- changing bindgen-flags header in the test headers to remove the --no-unstable-rust flag
- removing --no-unstable-rust flag in ./test/test-one.sh
Fixes #757
r? @fitzgen
|
|
- changing the Builder::no_unstable_rust method to the Builder::unstable_rust method
- changing the --no-unstable-rust flag to a --unstable-rust flag in src/options.rs
- changing bindgen-flags header in the test headers to remove the --no-unstable-rust flag
Fixes #757
|
|
Moar bitfield fixes
Now with the right branch name. See individual commits for details.
|
|
|
|
Item::is_constified_enum_module() only returns true for the base type, not for
"layers" of aliases.
Added a "simple alias" test and added content to the types test.
|
|
|
|
Check for correct arguments, quote variables, ensure exactly one test
file matches the pattern, and print usage information.
|
|
Like the ones seen in https://bugzilla.mozilla.org/show_bug.cgi?id=1365254#c22
|
|
Fixes #734
|
|
Correct mangling hack for win32
|
|
|
|
Fixes #755
|
|
|
|
|
|
|
|
ir: Make the workaround for LLVM bug 9069 more reliable.
Should fix https://github.com/zzeroo/libmodbus-rs/issues/4
|
|
Because I'm stupid.
|
|
Should fix https://github.com/zzeroo/libmodbus-rs/issues/4
|
|
|
|
|
|
Fixes #739
|
|
In particular, the "flush the allocation unit" logic is only valid for
ms_structs (that is, MSVC).
It's slightly annoying to have this different behavior, but it'd work just fine
if we'd turn that on for MSVC.
This patch doesn't do that, yet at least, and adds tests for all the weird
bitfield alignments around.
Fixes #726 (and another set of hidden issues by the old code).
|
|
Rather than having a tests that we only run if libclang >= 3.9, this makes the
test suite dynamically detect when we have different expectations for different
libclang versions. It does this by adding `tests/expectations/tests/libclang-$VERSION`
directories, and `testing_only_libclang_$VERSION` features that are consulted
when the usual expectation file does not exist.
Fixes #697
|
|
|
|
We should take any number of `// bindgen-$whatever` flags at the top of the
file. Only considering the first three lines of the file was confusing when I
tried adding new pragmas with an empty line between the new ones and old ones.
|
|
This is a temporary work around for issue #593 and this test failing on MacOS
because we don't currently handle when bindgen's target OS is not the same as
the emitted bindings' target OS.
|
|
Const function can't have variables or blocks.
|
|
Closes #711.
|
|
This should be good enough, following the pattern of anonymous items, and should
prevent most of the current noise in stylo updates.
Closes #620
Fixes #619
|
|
This commit gives bindgen the ability to generate constructors for bitfield
allocation units. This enables more ergonomic use of struct literals for
bindings structs that contain bitfields.
Additionally, when we are generating unstable Rust, these constructors are
marked as const functions. This enables the creation of const binding structs
that contain bitfields.
|
|
This commit moves bitfields and the computation of their allocation units into
the IR. They were previously computed on-the-fly during code generation. In
addition to breaking up and compartmentalizaing a portion of the gargantuan
`CodeGeneration` implementation for `CompInfo`, this paves the way for adding
const-fn bitfield unit constructors.
|
|
|
|
Allow running tests that don't have `bindgen-flags` pragmas. Less noisy
output. Show diff if the generated bindings differ from the expected bindings.
|
|
|
|
This fixes tests/expectations/tests/type_alias_template_specialized.rs in those
clang versions (without regressions, hopefully), and makes the behavior the
proper one, without needing replacements.
|
|
Otherwise you can't construct structs outside of the bindings file, which is
breaking.
Also, given the previous change was breaking and I didn't notice, I yanked
0.24.1.
|
|
|
|
This makes generated generic structs lifetime invariant, since we cannot know
the C++ type's true variance.
Fixes #506
|
|
Prefixes the clashing class method with class_ prefix
|
|
While parsing a Objective C property with function pointer type, bindgen hanged and died.
This is still not generating valid code function signature for the property, but at least it is not dying.
The actual fix was proposed by emilio.
|
|
The objetive-c template type params were handled as Typedefs so every
interface generated its own, clashing in the namespace. This now maps them to id.
|
|
Generate bindings to all headers passed to `Builder::header`
Inspired by real misconfiguration from inside stylo.
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.
r? @emilio
|
|
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.
|
|
|
|
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
|
|
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!
|
