| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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
|
|
Also renames a bunch of other things referring to named types to refer to type
parameters.
Fixes #915
|
|
|
|
|
|
|
|
Fixes #852
|
|
This makes only generating certain kinds of items more robust, since we don't
need to keep checking whether codegen is enabled for different kinds of items
all over the place, and can do it the once. It should also reduce the number of
items we have to consider in our various analyses for which we don't ultimately
care about the answer.
Fixes #826
|
|
Windows uses non-ascii and non-visual characters in mangled names T.T
|
|
|
|
|
|
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.
|
|
With this change, we can correctly parse C++ block comments.
```
/**
* Does a thing
*
* More documentation. This test does something
* useful.
*/
```
into
```
/// Does a thing
///
/// More documentation. This test does something
/// useful.
```
Fixes servo/rust-bindgen#426.
|
|
|
|
Because I'm stupid.
|
|
Fixes #727
|
|
Fixes #593
Fixes #728
|
|
generation.
|
|
Rust automatically adds one _ in the symbol. If we don't remove it, we will
endup getting three _.
|
|
While parsing a Objective C property with function pointer type, bindgen hanged and died.
This is still not generating valid code function signature for the property, but at least it is not dying.
The actual fix was proposed by emilio.
|
|
As pointed out in #653, clang 3.8 asserts when trying to mangle a C++
constructor or a destructor.
The following patch tries to use the `clang_Cursor_getCXXManglings` function
first.
This assumes that the last mangling we're interested in is the proper one, which
seems to be true looking at LLVM, and on trunk on my machine.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* 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
|
|
|
|
Add a workaround for #528, and fix #527
r? @fitzgen
|
|
|
|
|
|
This gives us more debug information in the emitted graphviz dot files.
|
|
|
|
This makes the IR traversal infrastructure generic. It makes it so we can use
the same traversal code for whitelisting traversals and asserting no dangling
item references. Therefore the queue of items to visit is generic (whitelisting
uses DFS, while asserting against dangling uses BFS), the storage for the seen
set (whitelisting uses a simple set, asserting against dangling uses a map from
item to the item from which it was discovered).
It also introduces the concept of different kinds of edges in the IR graph, and
the ability to choose which edges to follow. This means we can simplify
non-transitive whitelisting to a simple function that always returns "no do not
follow this edge". It plays an important part for future analysis of which
template declaration type parameters are used or not.
|
|
And its `collect_types` method to `trace`.
|
|
|
|
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/462
|
|
The problem with #425 was the following:
We were parsing the methods after reaching the JS::Value definition.
Those methods contained a JSWhyMagic that we hadn't seen, so we parsed it as
being in the JS:: module.
|
|
|
|
- The root crate is the `bindgen` binary
- Rust-ify the test suite, no more subprocesses!
- Update Travis config to test both crates
|
|
|
|
Rather than making `TypeCollector` implementations recursively call
`type_collector` on their subtypes, just gather immediate subtypes into
the `ItemSet`. The subtypes' `TypeCollector` implementation will be
recursively called by `WhitelistedItemsIter`. This makes it less likely
we will "skip" a layer by recursively calling `collect_types` on
some subtypes without adding the subtypes themselves to the set.
|
|
It has always been a mess.
|
|
|
