Age | Commit message (Collapse) | Author |
|
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.
|
|
|
|
Signed-off-by: Emilio Cobos Álvarez <ecoal95@gmail.com>
|
|
Add an option to avoid converting to f32/f64 automatically float types.
This implements another feature that we need for parity with upstream bindgen.
r? @fitzgen
|
|
|
|
|
|
This replaces the manual gathering and traversal of the transitive closure of
whitelisted items with the new canonical method.
|
|
|
|
|
|
https://github.com/rust-lang-nursery/rustfmt/issues/1184
|
|
This commit moves the `TypeCollector` trait out from the `codegen` module and
into its own submodule in `ir::type_collector`. Additionally, it puts the
various `TypeCollector` trait implementations next to the types that each
implementation is for.
|
|
This commit adds the `#![deny(missing_docs)]` pragma, which causes
compilation to fail if a public type or function is missing a
documentation comment. It also adds missing documentation comments for
public types and functions that were missing them.
|
|
Give vtables and anonymous items more stable generated names (fixes #60)
r? @emilio
This works pretty well. There are two remaining things in stylo's structs files that have identifiers that look like they won't be that stable: the anonymous enum for the NODE_* flags at the top level, and the `typedef union { ... } nsStyleUnion`. There are various anonymous enums and other things at the top level in system headers that cause these identifiers to have generated IDs in them higher than 1 and 2.
Probably for anonymous enums we could just avoid generating a rust enum altogether, since having the static consts should be sufficient. I tried to mess with the codegen to automatically treat `typedef union { ... } nsStyleUnion` like `union nsStyleUnion { ... }` but it seems the way clang exposes the typedef and union are as two adjacent cursors rather than a parent-child relationship, so it's not so easy.
|
|
|
|
Take pointer constness into account, to fix generation of const methods.
We signal method constness in the `this` pointer creating a `const` pointer, but the `to_rust_ty` implementation never checked that.
|
|
|
|
|
|
|
|
|
|
|