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.
|
|
Generate ptr::null rather than zero literal
|
|
|
|
Improve documentation of the integration tests
Also note the need to rebuild bindgen when running a single test.
r? @emilio
|
|
Also:
* disable rustfmt in the integration test, to avoid it causing problems, since
it is not needed.
* note the need to rebuild bindgen when running a single test.
|
|
Avoid bitfield getters and setters accessing memory beyond "self"
This fixes https://github.com/rust-lang-nursery/rust-bindgen/issues/954.
r? @emilio
|
|
This fixes https://github.com/rust-lang-nursery/rust-bindgen/issues/954.
|
|
Remove unnecessary flag from rustfmt invocation
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.
here's the logs when I leave the flag :
```
Error: file `--write-mode=display` does not exist
Error { repr: Custom(Custom { kind: Other, error: StringError("Internal rustfmt error") }) }
```
<details>
<summary>The build.rs : </summary>
```rust
extern crate bindgen;
use std::env;
use std::path::PathBuf;
fn main() {
println!("cargo:rustc-link-lib=static=transistor.nro");
println!("cargo:rustc-link-search=native=libtransistor/build/lib");
let bindings = bindgen::Builder::default()
.header("libtransistor/include/libtransistor/nx.h")
// Don't use host headers, to make sure we're building against newlib
.clang_arg("-nostdinc")
// Include the newlib/transistor headers, and the clang builtin headers
.clang_args(&["-isystem", "/usr/lib/clang/5.0.0/include"])
.clang_args(&["-isystem", "libtransistor/newlib/newlib/libc/include"])
.clang_args(&["-isystem", "libtransistor/newlib/newlib/libc/sys/switch/include"])
.clang_arg("-Ilibtransistor/include")
// We don't need to define those types, rust has them already anyways.
// Blacklisting avoids a bug in bindgen where it creates cyclic references
// (pub type u8 = u8)
.blacklist_type("u(8|16|32|64)")
.rustfmt_bindings(true)
.rustfmt_configuration_file(None)
.generate()
.expect("Unable to generate bindings");
let out_path = PathBuf::from(env::var("OUT_DIR").unwrap());
bindings
.write_to_file(out_path.join("bindings.rs"))
.expect("Couldn't write bindings!");
}
```
</details>
|
|
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.
|
|
Don't unwrap header metadata
Fix for a comment in #1092.
r? @fitzgen
|
|
|
|
Make bitfield unit allocation fallible
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
r? @pepyakin or @emilio
|
|
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
|
|
Stop using deprecated methods
r? @pepyakin
|
|
...instead of the deprecated `hide_type`.
|
|
...instead of the deprecated `hide_type` method.
|
|
Detect `#pragma pack(...)` and make `pack(n)` where `n > 1` opaque
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.
r? @emilio or @pepyakin
|
|
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.
|
|
Divide by zero in struct layout
See commit messages for details.
r? @emilio or @pepyakin
|
|
It isn't checking alignment at all; it's checking offsets.
|
|
|
|
Add a changelog
It is initially populated with information from our release announcements.
It has an "unreleased" section for accumulating notable changes that haven't been released yet, and to make it easier to summarize releases when we do publish them.
Fixes #1131
r? @emilio or @pepyakin
|
|
It is initially populated with information from our release announcements.
It has an "unreleased" section for accumulating notable changes that haven't
been released yet, and to make it easier to summarize releases when we do
publish them.
Fixes #1131
|
|
r=pepyakin
Actually cleanup temp files in predicate
Embarrassingly, we were ignoring and swallowing a dumb reference error that prevented the temp files from ever getting cleaned up.
The good news: with ignoring bitfields and packed structs, I got to `driver.py` iteration 27145 without triggering any `bindgen` bugs, and then the disk got full! :-p
r? @pepyakin
|
|
|
|
|
|
Unnamed bit-fields and alignment
r? @pepyakin or @emilio
|
|
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
|
|
|
|
ir: We can't guarantee the type to be in the item map while propagating 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
|
|
|
|
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
|
|
|
|
Minor version bump.
Again, just fixes, and I got FF to build with #1124.
|
|
|
|
ir: Don't eagerly-resolve template alias declarations.
Fixes #1118
|
|
Fixes #1118
|
|
Need mangle name of fields in struct for impl debug
Fix #1122 r? @fitzgen or @emilio or @pepyakin
|
|
|
|
|
|
Minor version bump.
Only bugfixes have landed since the last release (#1112 and #1114), apart from
doc fixes.
|
|
Only bugfixes have landed since the last release (#1112 and #1114), apart from
doc fixes.
|
|
ir: References have no implicit template parameters.
Fixes #1113.
|
|
lib: Always generate bindings.
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.
|
|
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.
|
|
Fix whitelisting documentation links in book.
While working on #990 depreciated the `whitelisted_function` I noticed a couple of links in the book that also should be updated to refer to the updated methods.
@fitzgen one question here, I assume I will also need to update the version number within the url as new documentation won't be built until the next release?
|