| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This should resolve #571. As discussed with @fitzgen I have moved the builtin-filtering out of `ast_dump` itself; this logic now happens at the point of call in `src/lib.rs`
|
|
|
|
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.
|
|
Make vtables non-zero-size to fix a rustc warning.
```
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
```
Emilio said on IRC:
> the empty vtable means that we don't care of figuring out the proper vtable layout, so we create an empty struct
Sounds like all that matters is to have a pointer, we don’t look at the data behind it. Using `c_void` seems appropriate, then.
|
|
```
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
```
|
|
https://github.com/servo/rust-bindgen/pull/597#issuecomment-288006557
|
|
options: Allow force-generating inline functions.
|
|
|
|
How would you suggest testing this?
|
|
Added tests and fixed missed function rename.
Fixed nits
Renamed visitor to callbacks.
Renamed visitor to callbacks.
Renamed visitor to callbacks.
Fixed text.
|
|
r=emilio
Resolve namespace clashes between methods and generated bitfield accessors
This commit makes bitfields' accessor codegen detect conflicting method names
and generate alternative, non-conflicting names instead.
Yes, I really hit this in SpiderMonkey...
r? @emilio
|
|
This commit makes bitfields' accessor codegen detect conflicting method names
and generate alternative, non-conflicting names instead.
|
|
Run tests with more versions of libclang
First, update our existing 3.8.X and 3.9.X libclang testing versions to their latest point releases. Second, add testing on the latest 3.7.X release and the latest 4.0.X release.
r? @emilio
|
|
First, update our existing 3.8.X and 3.9.X libclang testing versions to their
latest point releases. Second, add testing on the latest 3.7.X release and the
latest 4.0.X release.
|
|
Little helper stuff
A couple things that I've found helpful for iterative debugging.
r? @emilio
|
|
This adds the `EdgeKind` as a label to edges in the graphviz IR dump
output. This is useful for understanding why something is referenced by another
thing.
|
|
|
|
fitzgen:issue-573-even-more-spidermonkey-layout-test-failures, r=emilio
Refactor fallibility of conversions from IR to Rust types
The old `ToRustTy` and `ItemToRustTy` conversion traits were problematic in that they assumed infallibity. That assumption is problematic because we are often dealing with C++ constructs for which Rust has no equivalent *and* we don't have a usable layout from which to generate an opaque blob in its stead. But, a usable layout is often "up the stack" if only we had a way to get up there.
For example, Rust does not currently have an equivalent of const value template parameters, and libclang will not give us a layout for template definitions with const value template parameters. However, libclang will give us the layout for an instantiation of such a template definition.
First, this commit separates the concepts of generating an equivalent Rust type from generating an opaque blob of the same size and alignment as an IR thing. This consolidates and DRYs up a *ton* of code involved in falling back to an opaque blob (and doing our best to get a `Layout` for the blob) when we can't generate an equivalent Rust type for some IR thing.
Second, it separates fallible and infallible conversions, and provides a nice little framework for when to choose which. This gives us one single place where we do this whole dance:
if could not generate equivalent Rust type:
if we have a layout:
return opaque blob based on layout
else:
return opaque blob based on a wish and a prayer
The `ToRustTy` trait is replaced by the `TryToOpaque`, `ToOpaque`, `TryToRustTyOrOpaque`, and `ToRustTyOrOpaque` traits. The `ItemToRustTy` helper was just a way to avoid `ToRustTy`'s `Self::Extra` parameter when it was not needed, and is simply removed without a replacement. We suck it up and pass `&()` at call sites now. We *could* introduce `ItemTryToOpaque`, `ItemToOpaque`, etc... traits, but the cost of the added boiler plate would outweigh the benefits of not passing `&()` at call sites, IMHO.
In addition to being a nice code cleanup, this also fixes #573.
r? @emilio
|
|
The old ToRustTy and ItemToRustTy conversion traits were problematic
in that they assumed infallibity. That assumption is problematic
because we are often dealing with C++ constructs for which Rust has no
equivalent *and* we don't have a usable layout from which to generate
an opaque blob in its stead. But, a usable layout is often "up the
stack" if only we had a way to get up there.
For example, Rust does not currently have an equivalent of const value
template parameters, and libclang will not give us a layout for
template definitions with const value template parameters. However,
libclang will give us the layout for an instantiation of such a
template definition.
First, this commit separates the concepts of generating an equivalent
Rust type from generating an opaque blob of the same size and
alignment as an IR thing. This consolidates and DRYs up a *ton* of
code involved in falling back to an opaque blob (and doing our best to
get a Layout for the blob) when we can't generate an equivalent Rust
type for some IR thing.
Second, it separates fallible and infallible conversions, and provides
a nice little framework for when to choose which. This gives us one
single place where we do this whole dance:
if could not generate equivalent Rust type:
if we have a layout:
return opaque blob based on layout
else:
return opaque blob based on a wish and a prayer
The ToRustTy trait is replaced by the TryToOpaque, ToOpaque,
TryToRustTyOrOpaque, and ToRustTyOrOpaque traits. The ItemToRustTy
helper was just a way to avoid ToRustTy's Self::Extra parameter when
it was not needed, and is simply removed without a replacement. We
suck it up and pass `&()` at call sites now. We *could* introduce
ItemTryToOpaque, ItemToOpaque, etc... traits, but the cost of the
added boiler plate would outweigh the benefits of not passing `&()` at
call sites, IMHO.
In addition to being a nice code cleanup, this also fixes #573.
|
|
ir: Ignore non-finite macro constants from macros.
Fixes #582.
|
|
|
|
options: Honor distrust-clang-mangling.
|
|
fitzgen:issue-574-anonymous-template-parameters-and-assertion-failure, r=fitzgen
Allow anonymous template types
We have various assertions that the only way that some template parameter related methods will return `None` is if the template definition is marked opaque. These assertions fail in the presence of test cases with unnamed template types, because we never save an IR item for the template type, and subsequently think that the template definition has no template parameters. The assertions are in fact sound and correct, so it doesn't make sense to remove them. Instead it is more correct to save IR items for the anonymous template types and simply let the template usage analysis prevent them from getting
codegen'd.
Fixes #574
r? @emilio
|
|
|
|
Not sure why rustfmt hasn't caught this before...
|
|
We have various assertions that the only way that some template parameter
related methods will return `None` is if the template definition is marked
opaque. These assertions fail in the presence of test cases with unnamed
template types, because we never save an IR item for the template type, and
subsequently think that the template definition has no template parameters. The
assertions are in fact sound and correct, so it doesn't make sense to remove
them. Instead it is more correct to save IR items for the anonymous template
types and simply let the template usage analysis prevent them from getting
codegen'd.
Fixes #574
|
|
automatically allow non rust naming conventions
+ related issue: #562
I just added those attributes at the root mod. And I'm not sure whether it should be better if we could set this setting in `build.rs`.
|
|
Generate better opaque blobs in the face of non-type parameters
When instantiating templates whose definitions have non-type generic parameters, prefer the layout of the instantiation type to the garbage we get from the definition's layout. In general, an instantiation's layout will always be a better choice than the definition's layout, regardless of non-type parameters.
Fixes #569
r? @emilio
|
|
It reads a little bit better this way, but is exactly equivalent.
|
|
|
|
When instantiating templates whose definitions have non-type generic parameters,
prefer the layout of the instantiation type to the garbage we get from the
definition's layout. In general, an instantiation's layout will always be a
better choice than the definition's layout, regardless of non-type parameters.
Fixes #569
|
|
If we hit a case where we generate an opaque blob instead of an instantiation of
a generic, then we won't ever be attaching generic parameters, and can bail out
of the function early.
|
|
This pulls existing code out of Type's ToRustTy implementation and into an
implementation of ToRustTy for TemplateInstantiation. Purely code motion.
|
|
Reintroduce bitfield accessors
This commit reintroduces accessor methods for bitfields in the generated
bindings.
Fixes #519
r? @emilio
|
