| Age | Commit message (Collapse) | Author |
|---|
|
remove `clap` dependency :tada:
update the book installation instructions
|
|
|
|
Adding a custom derive like "serde::Deserialize" results in a panic complaining
that it is not a valid Ident. Derive params are not identifiers, so treat it as
a token stream instead.
|
|
|
|
space.
Fixes #1947.
There are two separate issues here: First, the change in comp.rs ensures
that we don't round up the amount of storage to the alignment of the
bitfield. That generates the "expected" output in #1947
(`__BindgenBitfieldUnit<[u8; 3], u16>`).
But that's still not enough to fix that test-case because
__BindgenBitfieldUnit would be aligned and have padding, and Rust won't
put the extra field in the padding.
In order to ensure the bitfield starts at the right alignment, but that
Rust can put stuff in the extra field, we need to make a breaking change
and split the generated fields in two: One preceding that guarantees
alignment, and the actual storage, bit-aligned.
This keeps the existing behavior while fixing that test-case.
|
|
|
|
`c_void` is available as `::std::os::raw::c_void` and
`::core::ffi::c_void`. If the "--use-core" option is specified (but no
--ctypes-prefix is provided), we should emit `::core::ffi::c_void`
rather than the `std` one.
|
|
|
|
Implements the feature discussed in
https://github.com/rust-lang/rust-bindgen/issues/1554.
|
|
|
|
Fixes https://github.com/rust-lang/rust-bindgen/issues/537.
|
|
This fixes a panic uncovered by the proc_macro update, which validates idents
now. We were using it as a pretty crappy way to turn it into something that
could be turned into a TokenStream. But TokenStream implements FromStr now.
|
|
I give up on the doc comments. This is a rebase of #1334 keeping the formatting
of the comments and using TokenStream::from_str instead because one can hope.
Fixes #1407.
|
|
|
|
|
|
This is very mechanical and boring, but needed.
|
|
blob() does care about alignment, so we can get into an architecture where there
are integers where size != align.
This is a tentative fix for https://github.com/servo/servo/issues/21093, though
as mentioned there I couldn't find a repro on my machine.
|
|
|
|
|
|
This reverts commit eb415c7a7cf8c72664dbfda5a614474cda5c185c.
|
|
This reverts commit 6899c275ee0ab0687ec66c490ddd1a76f8223513.
The `proc_macro2` crate depends on rustc internal crates, which means that
`bindgen` would need to be run under `rustup`.
We can follow https://github.com/rust-lang/rust/issues/47931 to get updates on
when this issue might be resolved and we can update `quote` again.
Fixes #1248
|
|
|
|
Individual bitfields are still limited to at most 64 bits, but this
restriction can be weakened when Rust supports u128.
This implements issue #816.
Usage notes:
* Since common code is added to each generated binding, a program which uses
more than one binding may need to work around the duplication by including
each binding in its own module.
* The values created by bitfield allocation unit constructors can be assigned
directly to the corresponding struct fields with no need for transmutation.
Implementation notes:
__BindgenBitfieldUnit represents a bitfield allocation unit using a Storage
type accessible as a slice of u8. The alignment of the unit is inherited from
an Align type by virtue of the field:
align: [Align; 0],
The position of this field in the struct is irrelevant.
The alignment of the Storage type is intended to be no larger than the
alignment of the Align type, which will be true if the Storage type is, for
example, an array of u8.
Although the double underscore (__) prefix is reserved for implementations of
C++, there are precedents for this convention elsewhere in bindgen and so the
convention is adopted here too.
Acknowledgement:
Thanks to @fitzgen for an initial implementation of __BindgenBitfieldUnit and
code to integrate it into bindgen.
|
|
|
|
attribute
|
|
The latest `rustfmt` has fixed the formatting bugs we were running into.
|
|
The `syntex` crate is unmaintained. It is slow to build, and additionally it
requires that we pre-process `src/codegen/mod.rs` before we build the `bindgen`
crate.
The `quote` crate provides similar quasi-quoting functionality, is maintained,
and builds faster. It doesn't have a typed API or builders, however; it only
deals with tokens.
Before this commit:
```
$ cargo clean; cargo build
<snip>
Finished dev [unoptimized + debuginfo] target(s) in 98.75 secs
```
After this commit:
```
$ cargo clean; cargo build
<snip>
Finished dev [unoptimized + debuginfo] target(s) in 46.26 secs
```
Build time is cut in half! But what about run time?
Before this commit:
```
Generated Stylo bindings in: Duration { secs: 3, nanos: 521105668 }
```
After this commit:
```
Generated Stylo bindings in: Duration { secs: 3, nanos: 548797242 }
```
So it appears to be about 20ms slower at generating Stylo bindings, but I
suspect this is well within the noise.
Finally, this also lets us remove that nasty `mem::transmute` inside
`bindgen::ir::BindgenContext::gen` that was used for the old `syntex`
context. Now `BindgenContext` doesn't have a lifetime parameter either. This
should make it easier to revisit doing our analyses in parallel with `rayon`,
since that context was one of the things that made it hard for `BindgenContext`
to implement `Sync`.
Fixes #925
|
|
Thanks @fitzgen for the detailed instructions.
Fixes #928.
|
|
Also renames a bunch of other things referring to named types to refer to type
parameters.
Fixes #915
|
|
This commit moves comment processing to a central place (well, two, because of
field docs, but that's fine).
Also, it makes comments indentation aware, so multiline comments don't appear
garbled.
Finally, it also fixes an out-of-bounds panic when processing an empty multiline
comment.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- The root crate is the `bindgen` binary
- Rust-ify the test suite, no more subprocesses!
- Update Travis config to test both crates
|
|
Proper fix on aster soon, still worth to get this in I guess.
r? @fitzgen
|
|
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.
|
|
https://github.com/rust-lang-nursery/rustfmt/issues/1184
|
|
|
|
TL;DR: The binding generator is a mess as of right now. At first it was funny
(in a "this is challenging" sense) to improve on it, but this is not
sustainable.
The truth is that the current architecture of the binding generator is a huge
pile of hacks, so these few days I've been working on rewriting it with a few
goals.
1) Have the hacks as contained and identified as possible. They're sometimes
needed because how clang exposes the AST, but ideally those hacks are well
identified and don't interact randomly with each others.
As an example, in the current bindgen when scanning the parameters of a
function that references a struct clones all the struct information, then if
the struct name changes (because we mangle it), everything breaks.
2) Support extending the bindgen output without having to deal with clang. The
way I'm aiming to do this is separating completely the parsing stage from
the code generation one, and providing a single id for each item the binding
generator provides.
3) No more random mutation of the internal representation from anywhere. That
means no more Rc<RefCell<T>>, no more random circular references, no more
borrow_state... nothing.
4) No more deduplication of declarations before code generation.
Current bindgen has a stage, called `tag_dup_decl`[1], that takes care of
deduplicating declarations. That's completely buggy, and for C++ it's a
complete mess, since we YOLO modify the world.
I've managed to take rid of this using the clang canonical declaration, and
the definition, to avoid scanning any type/item twice.
5) Code generation should not modify any internal data structure. It can lookup
things, traverse whatever it needs, but not modifying randomly.
6) Each item should have a canonical name, and a single source of mangling
logic, and that should be computed from the inmutable state, at code
generation.
I've put a few canonical_name stuff in the code generation phase, but it's
still not complete, and should change if I implement namespaces.
Improvements pending until this can land:
1) Add support for missing core stuff, mainly generating functions (note that
we parse the signatures for types correctly though), bitfields, generating
C++ methods.
2) Add support for the necessary features that were added to work around some
C++ pitfalls, like opaque types, etc...
3) Add support for the sugar that Manish added recently.
4) Optionally (and I guess this can land without it, because basically nobody
uses it since it's so buggy), bring back namespace support.
These are not completely trivial, but I think I can do them quite easily with
the current architecture.
I'm putting the current state of affairs here as a request for comments... Any
thoughts? Note that there are still a few smells I want to eventually
re-redesign, like the ParseError::Recurse thing, but until that happens I'm
way happier with this kind of architecture.
I'm keeping the old `parser.rs` and `gen.rs` in tree just for reference while I
code, but they will go away.
[1]: https://github.com/Yamakaky/rust-bindgen/blob/master/src/gen.rs#L448
|
