Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
Use the constness of the inner type when converting array function args.
Fixes https://github.com/servo/rust-bindgen/issues/509
I'm actually surprised we had no tests for this.
|
|
arguments.
Fixes https://github.com/servo/rust-bindgen/issues/509
I'm actually surprised we had no tests for this.
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
|
|
|
|
Also moves it out to its own ir::traversal module, and moves ItemSet to the
ir::item module.
|
|
Fixes: https://github.com/servo/rust-bindgen/issues/482
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It parses interfaces and protocol but ignores base classes, and their
methods which don’t have arguments, the method signature is currently
ignored. Also you can pass objc class instances to C functions.
Next steps are inheritance/base classes, method signatures, properties,
categories. Then check with system headers what is missing.
|
|
It's just dumb.
|
|
We do the same for template parameters with `typename` on aliases.
This is not great, but it's better than generating invalid code.
|
|
These aren't extremely great, since this usually requires extra bookkeeping. But
C allows it, so let's keep the same semantics.
|
|
|
|
|
|
This fails under BaseErrorResult in Stylo builds.
I have no idea right now why that isn't whitelisted (should be, given we're
calling it from TErrorResult's code generation).
Let's disable this pending further investigation since I don't have time to dig
into it right now.
|
|
So Rust is happy when you use them in template parameters, since the Derive
implementations can't catch this otherwise.
|
|
This is a useful debugging tool for us to catch when code generation and
whitelisting have different understandings of the world.
|
|
This is mostly a work around https://github.com/servo/rust-bindgen/issues/426,
until we implement the proper fix.
|
|
Forward declared structs now generate opaque enums
@emilio : I checked the test outputs again, and it seems that these changes are affecting struct *definitions* as well. Hence, I have not committed the test changes yet.
Fixes #62
|
|
|
|
codegen: Respect original repr for bitfield-like enums, add a constifying variant.
r? @fitzgen
Fixes #430
|
|
variant.
|
|
There's just no advantage in doing so.
|
|
The problem with #425 was the following:
We were parsing the methods after reaching the JS::Value definition.
Those methods contained a JSWhyMagic that we hadn't seen, so we parsed it as
being in the JS:: module.
|
|
|
|
|
|
|
|
- The root crate is the `bindgen` binary
- Rust-ify the test suite, no more subprocesses!
- Update Travis config to test both crates
|
|
|
|
Our debug-detection code assumes so.
Fixes #246
r? @fitzgen
|
|
Proper fix on aster soon, still worth to get this in I guess.
r? @fitzgen
|
|
Add support for bindings to overloaded functions
This commit (re)adds support for generating bindings to overloaded
functions. First, we use the symbol name instead of the canonical name
when checking if we have already generated bindings for a given
function. Second, we add a map from canonical names to number of times
we have generated a function with that canonical name. We increment this
number every time we generate a function. When the number is greater
than zero, we append it to the function name so that overloaded
functions get a unique Rust symbol.
Fixes #239
r? @emilio
|
|
This commit (re)adds support for generating bindings to overloaded
functions. First, we use the symbol name instead of the canonical name
when checking if we have already generated bindings for a given
function. Second, we add a map from canonical names to number of times
we have generated a function with that canonical name. We increment this
number every time we generate a function. When the number is greater
than zero, we append it to the function name so that overloaded
functions get a unique Rust symbol.
|
|
C complex only exists for floating point types.
C Complex are built in types
long double _Complex is not supported.
Long double would be an f128, runing generated binding test produces:
assertion failed: `(left == right)` (left: `16`, right: `32`)',
tests/expectations/tests/complex.rs:72
We test global long double _Complex because it does not require
layout tests.
Handle all the different way a complex can be present in
BindgenContext calling generated_bindegen_complex to indicate
that __BindgenContext will need to be added.
|
|
This adds `__float128` as a builtin type, and generates an opaque array
of 16 `u8`s to represent it in the generated bindings since Rust doesn't
have an `f128` type.
Context and motivation: Somehow `__float128` is getting pulled into
SpiderMonkey headers from somewhere, and the lack of `__float128`
support was causing bindgen to hard fail in bindings generation.
|
|
Parse macro expressions.
Clang is trolling me really hard so I'm going to see if the extra token I'm always getting is LLVM 3.9 specific.
|
|
|
|
|
|
default BitOr implementation.
|
|
|