| Age | Commit message (Collapse) | Author |
|---|
|
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).
|
|
Fixes #727
|
|
Fixes #593
Fixes #728
|
|
have proper clang support.
|
|
generation.
|
|
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
|
|
Const function can't have variables or blocks.
|
|
Rust automatically adds one _ in the symbol. If we don't remove it, we will
endup getting three _.
|
|
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 flattens the nesting in `Bitfield::extend_ctor_impl`, as requested
in review, because it was getting pretty deep. Should be easier to read now.
|
|
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.
|
|
|
|
ir: Handle properly template alias instantiations in clang >3.9
|
|
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.
|
|
Fixes #585
|
|
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
|
|
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
|
