| Age | Commit message (Collapse) | Author |
|---|
|
If we hit a case where we generate an opaque blob instead of an instantiation of
a generic, then we won't ever be attaching generic parameters, and can bail out
of the function early.
|
|
This pulls existing code out of Type's ToRustTy implementation and into an
implementation of ToRustTy for TemplateInstantiation. Purely code motion.
|
|
This commit reintroduces accessor methods for bitfields in the generated
bindings.
Fixes #519
|
|
|
|
|
|
All the template parameters!!
The major changes in this PR are:
* De-duplication of named template type parameters (this is probably the biggest part of the PR, and nastiest because it is the part that deals with libclang)
* Removing the `signature_contains_named_type` stuff, and enabling the more sound template type parameter usage analysis that has been landing in bits here and there.
* **LOTS** of new tests for template type parameter usage
@emilio: can you also test this on the stylo bindings? I tested on the SpiderMonkey bindings and found a bug and fixed a bug related to instantiations of partially specialized templates. I'd like to make sure that there aren't any latent bugs uncovered in Stylo.
This is NOT ready to merge quite yet, but is ready for some more eyeballs that are not mine.
Still TODO:
* [x] Rebase so that these changes will merge cleanly -- I'll get on this ASAP
* [x] Time SpiderMonkey bindings generation with and without these changes to see what the overhead of the new analysis is (if any!) on Large and Real World bindings
* [x] Test theses changes on Stylo (thanks @emilio!)
* [ ] (optional) and time Stylo bindings generation with and without these changes as well (only if you want to, @emilio)
Thanks!
|
|
* 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
|
|
Per C semantics, they may not.
|
|
The signedness of the C type 'char' is implementation defined. The
rust type c_schar exists for this reason. Use it.
|
|
Fixes #553
|
|
Currently the name of a enum is always prepended to the beginning of a const or bitfield like variant. This can result in some quite unintuivite naming, if the library already prefixes its variants. For example hundreds of variants are named like this `cs_arch_CS_ARCH_ARM` when binding to the capstone library.
This commit introduces a toggle for prepending the `cs_arch_` part. By default it is enabled to preserve current behaviour. It can be toggled with the `prepend_enum_name` function on the Builder.
|
|
|
|
Add more information to the graphviz output
|
|
|
|
|
|
|
|
|
|
Use the constness of the inner type when converting array function args.
Fixes https://github.com/servo/rust-bindgen/issues/509
I'm actually surprised we had no tests for this.
|
|
arguments.
Fixes https://github.com/servo/rust-bindgen/issues/509
I'm actually surprised we had no tests for this.
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
|
|
|
|
Also moves it out to its own ir::traversal module, and moves ItemSet to the
ir::item module.
|
|
Fixes: https://github.com/servo/rust-bindgen/issues/482
|
|
Template instantiation
I very much suspect this needs a rebase, but I haven't done it yet.
This is the majority of #446, although it doesn't have the name generation for anonymous named types patches yet (that will be a different PR).
|
|
|
|
|
|
check layout align before padding bytes
Fix issue #493 again :S
Still finding way to reproduce it
|
|
|
|
codegen: Fix remaining cases of missing core prefix.
Fixes #488
r? @fitzgen
|
|
|
|
check empty layout when padding bytes
fast workaround to fix issue #493
need to investigate why layout is empty
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
