| Age | Commit message (Collapse) | Author |
|---|
|
Add option to not add enum name to bitfield or constant variants
Many C libraries prefix the variants of their enums already, because C enums are not scoped. That means if bindgen prefixes them again that can lead to ugly names like `cs_arch_CS_ARCH_ARM`. The `cs_arch_` part comes from the name of the enum itself and `CS_ARCH_ARM` is the name of the actual variant.
This pull request introduces a variable for changing this behaviour, alongside command line flags and a test case. If `prepend_enum_names` is set to false the resulting variant name will be `CS_ARCH_ARM` instead of `cs_arch_CS_ARCH_ARM` as it is now.
If there is anything that could be improved, or this toggle already exists (I have not found anything like that), please let me know.
|
|
|
|
|
|
Currently the name of a enum is always prepended to the beginning of a const or bitfield like variant. This can result in some quite unintuivite naming, if the library already prefixes its variants. For example hundreds of variants are named like this `cs_arch_CS_ARCH_ARM` when binding to the capstone library.
This commit introduces a toggle for prepending the `cs_arch_` part. By default it is enabled to preserve current behaviour. It can be toggled with the `prepend_enum_name` function on the Builder.
|
|
lib: Simplify the libclang setup.
r? @fitzgen
|
|
Add a workaround for #528, and fix #527
r? @fitzgen
|
|
Gotta land some of this stuff...
My patch queue is getting quite large, as I refactor templates in bindgen, so I figure I should land the stuff that is in good shape sooner rather than later :-P
This stuff tweaks the named template parameter analysis, adds some edge kinds, stuff like that. This is still not used by codegen, yet. I have another branch where I de-dupe named types and all of that, and there is only two tests failing now, but still some clean up needed.
This also contains the expanded documentation for te named template parameter analysis that I promised.
See each commit message for details.
r? @emilio
|
|
More objective c features
These changes implement the `id` and `SEL` type, `@class` forward declaration handling (though very superficially), and also renames the traits generated from protocols to have a `protocol_` prefix.
With these, I'm able to parse and compile NSObject.h, but I haven't really tested using it yet.
|
|
Disable osx testing.
Not only for the large build times, but also because builds have been stalled
for long, and I had to merge a few PRs manually already.
r? @fitzgen
|
|
Not only for the large build times, but also because builds have been stalled
for long, and I had to merge a few PRs manually already.
|
|
Apparently protocols and interface names live in a separate namespace,
so there is a chance of collision, like the NSObject interface implements NSObject category
|
|
|
|
Rather than determining whether any given template parameter is used at all
globally, determine the set of template parameters used by any given IR node.
|
|
|
|
The all_template_parameters method gets the complete set of template parameters
that can affect a given item.
Note that this item doesn't need to be a template declaration itself for `Some`
to be returned from this method (in contrast to `self_template_params`). If this
item is a member of a template declaration, then the parent's template
parameters are included here. See the example in TemplateDeclaration's doc
comment for details.
|
|
|
|
limit padding bytes align less than structure’s
|
|
Support older clang
|
|
Add more information to the graphviz output
|
|
force pad bytes before field with large aligement
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This gives us more debug information in the emitted graphviz dot files.
|
|
|
|
Create ISSUE_TEMPLATE.md
Github will automatically fill this in when people file new issues.
New PR because apparently I can't push to servo anymore... I think this is the same issue as with tags...
|
|
Add an example image of our IR rendered with graphviz
This turned out really great! I can't wait to use this when debugging :)
r? @emilio
cc @impowski :)
cc @jdm here is a screenshot for TWiS :)
|
|
|
|
Github will automatically fill this in when people file new issues.
|
|
Rework how bitfields are handled.
This fixes #111, and unblocks stylo.
The problem with this as of right now is that it drops the accessors (though before that this code was buggy so I'm not sure it's a loss).
I can probably try to re-implement those (though it'd be more complex). WDYT @fitzgen?
Also, note that I changed the max_align_nonce because it was incorrect (we shouldn't generate padding, because `long double` was `128` bits).
|
|
|
|
|
|
typedef struct {} name
Fixes #427
It looks like clang is doing the hard work of getting the right name from the typedef, but it falls back to arbitrary pretty-printed descriptions if it can't find a typedef. I couldn't find an API to check whether the name comes from a typedef, so I just filter out non-ident-like spellings.
|
|
Graphviz implementation
This will solve #484 . Right now it's really basic and I will change some of things in future commits like docs and other things.
r? @fitzgen
|
|
|
|
|
|
|
|
|
|
Update clang-sys.
Fixes https://github.com/servo/rust-bindgen/issues/439
r? @fitzgen
|
|
|
|
|
|
|
|
Fixes https://github.com/servo/rust-bindgen/issues/439
|
|
Discover which template type parameters are actually used
This is just landing the initial analysis, and does not start leveraging this analysis's results instead of using the `Item::signature_contains_named_type` method yet.
r? @emilio
|
|
C++ allows ignoring template parameters, while Rust does not. Usually we can
blindly stick a `PhantomData<T>` inside a generic Rust struct to make up for
this. That doesn't work for templated type aliases, however:
```C++
template <typename T>
using Fml = int;
```
If we generate the naive Rust code for this alias, we get:
```ignore
pub type Fml<T> = ::std::os::raw::int;
```
And this is rejected by `rustc` due to the unused type parameter.
(Aside: in these simple cases, `libclang` will often just give us the
aliased type directly, and we will never even know we were dealing with
aliases, let alone templated aliases. It's the more convoluted scenarios
where we get to have some fun...)
For such problematic template aliases, we could generate a tuple whose
second member is a `PhantomData<T>`. Or, if we wanted to go the extra mile,
we could even generate some smarter wrapper that implements `Deref`,
`DerefMut`, `From`, `Into`, `AsRef`, and `AsMut` to the actually aliased
type. However, this is still lackluster:
1. Even with a billion conversion-trait implementations, using the generated
bindings is rather un-ergonomic.
2. With either of these solutions, we need to keep track of which aliases
we've transformed like this in order to generate correct uses of the
wrapped type.
Given that we have to properly track which template parameters ended up used
for (2), we might as well leverage that information to make ergonomic
bindings that don't contain any unused type parameters at all, and
completely avoid the pain of (1).
Determining which template parameters are actually used is a trickier
problem than it might seem at a glance. On the one hand, trivial uses are
easy to detect:
```C++
template <typename T>
class Foo {
T trivial_use_of_t;
};
```
It gets harder when determining if one template parameter is used depends on
determining if another template parameter is used. In this example, whether
`U` is used depends on whether `T` is used.
```C++
template <typename T>
class DoesntUseT {
int x;
};
template <typename U>
class Fml {
DoesntUseT<U> lololol;
};
```
We can express the set of used template parameters as a constraint solving
problem (where the set of template parameters used by a given IR item is the
union of its sub-item's used template parameters) and iterate to a
fixed-point.
We use the "monotone framework" for this fix-point analysis where our
lattice is the powerset of the template parameters that appear in the input
C++ header, our join function is set union, and we use the
`ir::traversal::Trace` trait to implement the work-list optimization so we
don't have to revisit every node in the graph when for every iteration
towards the fix-point.
For a deeper introduction to the general form of this kind of analysis, see
[Static Program Analysis by Anders Møller and Michael I. Schwartzbach][spa].
[spa]: https://cs.au.dk/~amoeller/spa/spa.pdf
|
