| Age | Commit message (Collapse) | Author |
|---|
|
First, update our existing 3.8.X and 3.9.X libclang testing versions to their
latest point releases. Second, add testing on the latest 3.7.X release and the
latest 4.0.X release.
|
|
fitzgen:issue-573-even-more-spidermonkey-layout-test-failures, r=emilio
Refactor fallibility of conversions from IR to Rust types
The old `ToRustTy` and `ItemToRustTy` conversion traits were problematic in that they assumed infallibity. That assumption is problematic because we are often dealing with C++ constructs for which Rust has no equivalent *and* we don't have a usable layout from which to generate an opaque blob in its stead. But, a usable layout is often "up the stack" if only we had a way to get up there.
For example, Rust does not currently have an equivalent of const value template parameters, and libclang will not give us a layout for template definitions with const value template parameters. However, libclang will give us the layout for an instantiation of such a template definition.
First, this commit separates the concepts of generating an equivalent Rust type from generating an opaque blob of the same size and alignment as an IR thing. This consolidates and DRYs up a *ton* of code involved in falling back to an opaque blob (and doing our best to get a `Layout` for the blob) when we can't generate an equivalent Rust type for some IR thing.
Second, it separates fallible and infallible conversions, and provides a nice little framework for when to choose which. This gives us one single place where we do this whole dance:
if could not generate equivalent Rust type:
if we have a layout:
return opaque blob based on layout
else:
return opaque blob based on a wish and a prayer
The `ToRustTy` trait is replaced by the `TryToOpaque`, `ToOpaque`, `TryToRustTyOrOpaque`, and `ToRustTyOrOpaque` traits. The `ItemToRustTy` helper was just a way to avoid `ToRustTy`'s `Self::Extra` parameter when it was not needed, and is simply removed without a replacement. We suck it up and pass `&()` at call sites now. We *could* introduce `ItemTryToOpaque`, `ItemToOpaque`, etc... traits, but the cost of the added boiler plate would outweigh the benefits of not passing `&()` at call sites, IMHO.
In addition to being a nice code cleanup, this also fixes #573.
r? @emilio
|
|
The old ToRustTy and ItemToRustTy conversion traits were problematic
in that they assumed infallibity. That assumption is problematic
because we are often dealing with C++ constructs for which Rust has no
equivalent *and* we don't have a usable layout from which to generate
an opaque blob in its stead. But, a usable layout is often "up the
stack" if only we had a way to get up there.
For example, Rust does not currently have an equivalent of const value
template parameters, and libclang will not give us a layout for
template definitions with const value template parameters. However,
libclang will give us the layout for an instantiation of such a
template definition.
First, this commit separates the concepts of generating an equivalent
Rust type from generating an opaque blob of the same size and
alignment as an IR thing. This consolidates and DRYs up a *ton* of
code involved in falling back to an opaque blob (and doing our best to
get a Layout for the blob) when we can't generate an equivalent Rust
type for some IR thing.
Second, it separates fallible and infallible conversions, and provides
a nice little framework for when to choose which. This gives us one
single place where we do this whole dance:
if could not generate equivalent Rust type:
if we have a layout:
return opaque blob based on layout
else:
return opaque blob based on a wish and a prayer
The ToRustTy trait is replaced by the TryToOpaque, ToOpaque,
TryToRustTyOrOpaque, and ToRustTyOrOpaque traits. The ItemToRustTy
helper was just a way to avoid ToRustTy's Self::Extra parameter when
it was not needed, and is simply removed without a replacement. We
suck it up and pass `&()` at call sites now. We *could* introduce
ItemTryToOpaque, ItemToOpaque, etc... traits, but the cost of the
added boiler plate would outweigh the benefits of not passing `&()` at
call sites, IMHO.
In addition to being a nice code cleanup, this also fixes #573.
|
|
ir: Ignore non-finite macro constants from macros.
Fixes #582.
|
|
|
|
options: Honor distrust-clang-mangling.
|
|
fitzgen:issue-574-anonymous-template-parameters-and-assertion-failure, r=fitzgen
Allow anonymous template types
We have various assertions that the only way that some template parameter related methods will return `None` is if the template definition is marked opaque. These assertions fail in the presence of test cases with unnamed template types, because we never save an IR item for the template type, and subsequently think that the template definition has no template parameters. The assertions are in fact sound and correct, so it doesn't make sense to remove them. Instead it is more correct to save IR items for the anonymous template types and simply let the template usage analysis prevent them from getting
codegen'd.
Fixes #574
r? @emilio
|
|
|
|
Not sure why rustfmt hasn't caught this before...
|
|
We have various assertions that the only way that some template parameter
related methods will return `None` is if the template definition is marked
opaque. These assertions fail in the presence of test cases with unnamed
template types, because we never save an IR item for the template type, and
subsequently think that the template definition has no template parameters. The
assertions are in fact sound and correct, so it doesn't make sense to remove
them. Instead it is more correct to save IR items for the anonymous template
types and simply let the template usage analysis prevent them from getting
codegen'd.
Fixes #574
|
|
automatically allow non rust naming conventions
+ related issue: #562
I just added those attributes at the root mod. And I'm not sure whether it should be better if we could set this setting in `build.rs`.
|
|
Generate better opaque blobs in the face of non-type parameters
When instantiating templates whose definitions have non-type generic parameters, prefer the layout of the instantiation type to the garbage we get from the definition's layout. In general, an instantiation's layout will always be a better choice than the definition's layout, regardless of non-type parameters.
Fixes #569
r? @emilio
|
|
It reads a little bit better this way, but is exactly equivalent.
|
|
|
|
When instantiating templates whose definitions have non-type generic parameters,
prefer the layout of the instantiation type to the garbage we get from the
definition's layout. In general, an instantiation's layout will always be a
better choice than the definition's layout, regardless of non-type parameters.
Fixes #569
|
|
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.
|
|
Reintroduce bitfield accessors
This commit reintroduces accessor methods for bitfields in the generated
bindings.
Fixes #519
r? @emilio
|
|
Do not print builtin macro definitions in ast_dump
Resolves issue #476. Moves out logic for checking whether a cursor has a filename (previously used exclusively in private function lib::filter_builtins) into the actual cursor. This code is then used to check whether a cursor is a builtin when dumping the AST.
|
|
This commit reintroduces accessor methods for bitfields in the generated
bindings.
Fixes #519
|
|
|
|
Resolves issue #476. Moves out logic for checking whether a cursor has a filename (previously used exclusively in private function lib::filter_builtins) into the actual cursor. This code is then used to check whether a cursor is a builtin when dumping the AST.
|
|
|
|
objc: Implement class methods
Ah yes, I was still missing class methods.
They are handled pretty much identically with instance methods, except for in the codegen it needs to know the class name.
|
|
|
|
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
|
|
fix clang installation instruction for debian os
Added clang-3.9 to debian install command. Without it, `cargo build` of [libbindgen-tutorial-bzip2-sys](https://github.com/fitzgen/libbindgen-tutorial-bzip2-sys) fails with:
```
/usr/include/stdio.h:33:11:` fatal error: 'stddef.h' file not found, err: true
```
|
|
|
|
codegen: Don't assume unsized structs have address.
Per C semantics, they may not.
r? @fitzgen
|
|
Per C semantics, they may not.
|
|
Run without logging feature
The build was broken without default features
|
|
|
|
Use c_schar instead of c_char
The signedness of the C type 'char' is implementation defined. The
rust type c_schar exists for this reason. Use it.
|
|
Bump to v0.22.1
There've been no breaking changes in v0.22.0..HEAD, only a bunch of bugfixes.
|
|
There've been no breaking changes in v0.22.0..HEAD, only a bunch of bugfixes.
|
|
The signedness of the C type 'char' is implementation defined. The
rust type c_schar exists for this reason. Use it.
|
|
objc: Implement whitelist tracing
This implements the tracing facility to enable whitelisting.
The most ugly thing is the collecting of the protocol ItemIds that a interface conforms to. I couldn't use the Item::from_ty because the protocols aren't actually types (in clang), I'm just making them look like one, as thats how they behave in bindgens perspective. So I resorted in linear search of all ItemIds, as it was easyish to implement (local to objc.rs), but there are several good avenues to make that faster if it needs to.
The change to naming the types with the rust_name is also a suspect, I'm not totally sure of all the consequences but this allows the protocols/categories to be disambiguated, otherwise there could be multiple type items with the same name. Somehow I feel that I'm forgetting another rationale as well, from when I originally wrote that line few days ago.
Locally I also got a test failure, but to me that does not seem like it was caused by these changes. In call-conv-field.rs:
```diff
extern "stdcall" {
- #[link_name = "_bar@0"]
+ #[link_name = "bar@0"]
pub fn bar();
}
```
|
|
|
|
Keeps note of the ItemIds that the Objective C interface conforms to,
and when tracing, visits also them.
|
|
Follows all the method signatures
|
|
Allows to disambiguate protocols and interfaces in whitelists
|
|
codegen: Don't pad union fields.
Fixes #553
|
|
Fixes #553
|
|
Fix calling convention propagation for function pointers.
This sucks, but works.
The full solution is a refactoring that needs more thought than the time I'm
able to dedicate to bindgen right now, see the comment for details.
r? @fitzgen
|
|
And I don't want nor have the time to debug it right now.
|
|
|
|
This sucks, but works.
The full solution is a refactoring that needs more thought than the time I'm
able to dedicate to bindgen right now, see the comment for details.
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
|
|
clang: Avoid a hot FFI call for getting the cursor kind.
This is a sorta-hot call already.
I've noticed #544 wants to add more assertions about this, and was going to
suggest moving them to `debug_assert!`.
But there's an easier way :)
r? @fitzgen
|
|
This is a sorta-hot call already.
I've noticed #544 wants to add more assertions about this, and was going to
suggest moving them to `debug_assert!`.
But there's an easier way :)
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
|
