| Age | Commit message (Collapse) | Author |
|---|
|
Support bitfield allocation units larger than 64 bits
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.
It is assumed that the alignment of the `Storage` type is no larger than the
alignment of the `Align` type, which will be true if the `Storage` type is, for
example, an array of `u8`. This assumption is checked in a debug assertion.
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.
r? @emilio
|
|
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.
|
|
|
|
This fixes https://github.com/rust-lang-nursery/rust-bindgen/issues/954.
|
|
From rustfmt docs, the --write-mode flag is unecessary when passing the
flag to stdin. If we leave it there, rustfmt-nightly complains that it
cannot find the file named --write-mode, so let's remove the flag.
|
|
|
|
Instead of panicking when we see a bitfield that does not have a layout, return
an error up the stack. If we get an error when allocating bitfields into units,
then make the whole struct opaque.
Fixes #1140
|
|
This is a bandaid for #537. It does *not* fix the underlying issue, which
requires `#[repr(packed = "N")]` support in Rust. However, it does make sure
that we don't generate type definitions with the wrong layout, or fail our
generated layout tests.
|
|
It isn't checking alignment at all; it's checking offsets.
|
|
|
|
According to the x86[-64] ABI spec: "Unnamed bit-fields’ types do not affect the
alignment of a structure or union". This makes sense: such bit-fields are only
used for padding, and we can't perform an un-aligned read of something we can't
read because we can't even name it.
Fixes #1076
|
|
|
|
AlreadyResolved.
The item may come from a recursive check down the stack, and as we say there:
> Unchecked because we haven't finished this type yet.
Fixes #1127
|
|
Simple refactoring of derive_partialeq_or_partialord
Just simple refactoring with some tricks from https://github.com/rust-lang-nursery/rust-bindgen/pull/1102
r? @fitzgen
|
|
|
|
Fixes #1118
|
|
|
|
|
|
ir: References have no implicit template parameters.
Fixes #1113.
|
|
Fixes #1113.
|
|
Some cases in spawning rustfmt were not properly returning the source. Make it
more reliable.
This hit me when trying to update bindgen in Firefox.
|
|
Simplify the rustfmt and write mechanism. Use rustfmt generated string to allow
writing to stdout or to rustfmt a file.
|
|
|
|
|
|
Resolve #962 - implement --no-copy with tests
Allows types to not have the copy trait automatically derived.
|
|
|
|
This fixes a couple bugs where we weren't properly adding an `_address`
byte. It also helps pave the way for computing implicit fields (such as padding,
`_address`, vtable pointers, etc) in its own pass, before codegen.
Fixes #768
|
|
generated bindings from test headers
|
|
Derive `Clone` along with `Copy` on Rust 1.21
Fixes #934
r? @fitzgen or @emilio
|
|
ir: Cleanup a bunch of constructors
Should be no change in behavior.
|
|
Issue #1029: Print error messages if header is a folder or unreadable
r? @fitzgen
|
|
|
|
Store function linkage in the ir
This lets us capture 'static inline' functions in the ir and filter them
later down the pipeline. This is the first step on the way to handling
these functions better.
|
|
To use the shorthand initialization syntax.
|
|
This lets us capture 'static inline' functions in the ir and filter them
later down the pipeline. This is the first step on the way to handling
these functions better.
|
|
|
|
|
|
instead
|
|
pointer
|
|
|
|
`HasVtableAnalysis`
|
|
We were not checking signed-ness and emitting the appropriate types.
Fixes #1040
|
|
Move `self` into `ir::BindgenContext::gen`
Small clean up. See each commit for details.
r? @pepyakin
|
|
`bindgen` follows a pipeline architecture, and we only ever generate bindings
once. By taking ownership of `self`, we can enforce this. We can also remove
checks inside `gen` for whether we have resolved type refs or not, since we now
know that we haven't because it is guaranteed to only be called the one time.
|
|
`parse_one` was never supposed to be public and it uses a bunch of non-public
types as a parameters, so downstream crates wouldn't be able to call it anyways.
|
|
Its more clear what the methods/fields are returning/storing when we add "width"
to the name.
|
|
|
|
|
|
Emit hex bitfield masks
r? @fitzgen
|
|
|
