| Age | Commit message (Collapse) | Author |
|---|
|
remove `clap` dependency :tada:
update the book installation instructions
|
|
This doesn't change behavior but makes the code make more sense.
|
|
The --explicit-padding flag would make bindgen try to add tail padding
to rust unions, by adding up the size of all the union fields and
subtracting from the size of the union as given by clang. The total size
of a union's fields is always larger than the union, so the subtraction
underflowed and bindgen produced padding fields larger than addressable
RAM.
|
|
|
|
If a struct needs to be serialized in its native format (padding bytes
and all), for example writing it to a file or sending it on the network,
then explicit padding fields are necessary, as anything reading the
padding bytes of a struct may lead to Undefined Behavior.
|
|
Instead of always generating the _bindgen_union_align method (which
shouldn't be needed at all for Rust structs, since the struct layout
tracker already deals with adding repr(align) as necessary) make sure to
visit all fields appropriately to generate the correct alignment.
|
|
This can cause unnecessary padding to be computed otherwise at the end
of the struct.
With repr(packed(n)), a field can have padding to adjacent fields as
long as its alignment is less than n. So reuse the code we have to align
to a field layout, aligning to the struct layout instead.
Fixes #1934
|
|
|
|
|
|
|
|
Before repr(align), we could only safely guarantee up to 8-bytes of alignment (I
think the pointer-width check is a more conservative way of doing that, in
practice, because I _think_ u64 is 8-byte aligned even for smaller targets).
So when we may generate a potentially-under-aligned struct, we always used to
pad it so as to guarantee that at least the size (and thus reads from rust for
C-allocated structs) was fine.
But if we support repr(align), then the above is always unneeded.
|
|
|
|
This makes us not unnecessarily add repr(align) to unions.
Closes #1498.
|
|
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.
|
|
To work-around some cases of https://github.com/rust-lang/rust/issues/54341.
Other cases where u128 and u64 are mixed in fields might not behave correctly,
but the field offset assertions would catch them.
Fixes #1370
|
|
This is very mechanical and boring, but needed.
|
|
|
|
This reverts commit eb415c7a7cf8c72664dbfda5a614474cda5c185c.
|
|
Plus fix the check that avoids us generating explicit alignment fields for
structs aligned to more than pointer-size.
Fixes #1291
|
|
Closes #1284
|
|
Use the ? operator instead of try, and add some more uses of it on Option<> that
were straight-forward.
|
|
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
|
|
|
|
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.
|
|
|
|
|
|
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 bitfields and the computation of their allocation units into
the IR. They were previously computed on-the-fly during code generation. In
addition to breaking up and compartmentalizaing a portion of the gargantuan
`CodeGeneration` implementation for `CompInfo`, this paves the way for adding
const-fn bitfield unit constructors.
|
|
* Find each item's used template parameters when we begin the codegen phase
* Add TemplateDeclaration::used_template_params()
This method is available during the codegen phase, and uses the information
gleaned by the `ir::named::UsedTemplateParameters` analysis.
* Remove Item::{applicable_template_args,signature_contains_named_type}
They are replaced by the template parameter usage analysis and
TemplateDeclaration::used_template_params.
* Parse and de-duplicate named template type parameters
* Do not attempt to determine template parameter usage when not recursively whitelisting
* Add a proper TemplateInstantiation type
This makes it so that CompInfo is always either a compound type definition, or a
template compound type definition, never an instantiation of a template. It also
pulls out TypeKind::TemplateInstantiation(<inline stuff>) to a proper
ir::TemplateInstantiation type, and TypeKind::TemplateInstantiation just wraps
ir::TemplateInstantiation into TypeKind.
* Allow template definitions to lack template parameters because of opaque template definitions
* Detect and ignore cycles deriving Copy/Debug and whether a type has a vtable
* Bail out early in the face of partial template specialization
We don't support it, and shouldn't continue trying to parse a type from this
cursor.
* Do not consider inner type's parameter usage as our own parameter usage
* Do not require a parent_id for template instantiations
It is not necessary, and in fact was preventing us from creating template
instantiations in some places, resulting in such nonsense as a generic template
definition as a base for another type.
* Only join if this is NOT a named template type or a template instantiation
Otherwise, we'll always consider all of a template instantiation's arguments as
used, when they should only be considered used if the template definition uses
that template parameter.
* Consider function return and parameter types as used
Although we should not follow class method edges because we cannot create new
monomorphizations of methods, code can create aliases of function pointers whose
return or parameter types are template parameters, and those template parameters
should be considered used.
* Add the AsNamed trait for things which might be a named template type
This sees through ResolvedTypeReferences to get at the final named type and its
canonical item id. By using this in the named template parameter usage analysis,
we ensure we don't have bugs where there are ResolvedTypeReferences in the usage
sets rather than the canonical named item id, which could cause template
parameters to be ignored accidentally.
* Do not consider an inner var's template parameter usage as our own
* Make the expectations' tests less noisy
* Use opaque blobs for unknown template definition types
When we don't know how to generate a Rust type from a template definition (eg
because it uses non-type template parameters), then we should fall back to using
the instantiation's layout to generate the opaque blob.
* Implement CanDeriveDebug for TemplateInstantiation
We need the template instantiation's layout to determine if we can derive debug
for it when the instantiation's template definition has non-type parameters.
* Stop thrashing malloc when unioning ItemSets in UsedTemplateParameters
Previously, we were cloning an ItemSet, which requires a malloc for non-empty
sets, when taking its union with our current id's set. Now, instead of doing
that, we wrap each ItemSet in an Option, and take the set out of the hash map
when modifying it. This allows us to side-step the borrow checker and HashMap's
lack of an analog to `slice::split_at_mut` and mutate what is logically a value
in the hash map while also using immutable references of values that are
physically in the hash map.
* Add some tests explicitly about template parameter usage
* Updated test expectations now that we are inferring template parameter usage
* Reinstate the layout tests for template instantiations
* Generate opaque blobs for uses of partially specialized templates
This adds `TypeKind::Opaque` which signifies that we do not understand anything
about the given type and that we should just generate an opaque blob based on
the type's layout. It explicitly uses the opaque type kind for partially
specialized templates.
* Add note about None vs Some([]) in TemplateDeclaration
* Do not rely on TypeKind implementing PartialEq
* Prefer assert_eq!(lhs, rhs) to assert!(lhs == rhs)
* Expand some comments for ir::named::UsedTemplateParameters
* Expand Item::is_opaque to consider TypeKind::Opaque
* Use opaque types instead of panicking
Use opaque types as our last resort when resolving type references after we have
collected unresolved type references instead of panicking.
* Find template definitions that don't want to be found
* Recognize associated template types and make them opaque
|
|
|
|
|
|
|
|
|
|
|
