| Age | Commit message (Collapse) | Author |
|---|
|
If a template has a specialization that bindgen doesn't understand, it can be
helpful to mark it as opaque and continue making forward progress in the
meantime. This is something we need in the SpiderMonkey bindings.
|
|
Feature 699 constified enum module
This is a work in progress for issue #699 that adds the `--constified-enum-module` option to bindgen.
@emilio, could you give me some guidance on fixing the uses of the enum variant types? In the example below, `foo` should be replaced with `foo::Type`. I'm not sure of the proper way to rename `Item`s after the structures have been defined. My initial thought was to redefine the `CodeGenerator` trait to take a mutable reference to `item`, but that will not work because of the borrow checker. Thoughts?
Todo:
- [x] put constified enum variants in a `mod`
- [x] ensure references to constified enum `foo` are changed to `foo::Type`
- [x] handle `typedef` enums
-----
Given the input header `tests/headers/constify-module-enums.h`:
~~~c
// bindgen-flags: --constified-enum-module foo
enum foo {
THIS,
SHOULD_BE,
A_CONSTANT,
};
struct bar {
enum foo this_should_work;
};
~~~
`$ cargo run -- tests/headers/constify-module-enums.h --constified-enum-module foo --no-layout-tests` will output:
~~~rust
/* automatically generated by rust-bindgen */
pub mod foo {
pub type Type = ::std::os::raw::c_uint;
pub const THIS: Type = 0;
pub const SHOULD_BE: Type = 1;
pub const A_CONSTANT: Type = 2;
}
#[repr(C)]
#[derive(Debug, Copy)]
pub struct bar {
pub this_should_work: foo,
}
impl Clone for bar {
fn clone(&self) -> Self { *self }
}
~~~
|
|
Ensure that every item is in some module's children list
Previously, if an item's parent was not a module (eg a nested class definition whose parent it the outer class definition) and the parent was not whitelisted but the item was transitively whitelisted, then we could generate uses of the item without emitting any definition for it. This could happen because we were relying on the outer type calling for code generation on its inner types, but that relies on us doing code generation for the outer type, which won't happen if the outer type is not whitelisted.
This commit avoids this gotcha by ensuring that all items end up in a module's children list, and so will be code generated even if their parent is not whitelisted.
This does have the downside of changing the relative order of some of the emitted code, and so this has a big diff (as will the next bindgen update for downstream dependencies) but I actually think the newer order makes more sense, for what that is worth.
Fixes #769
r? @emilio
|
|
Previously, if an item's parent was not a module (eg a nested class definition
whose parent it the outer class definition) and the parent was not whitelisted
but the item was transitively whitelisted, then we could generate uses of the
item without emitting any definition for it. This could happen because we were
relying on the outer type calling for code generation on its inner types, but
that relies on us doing code generation for the outer type, which won't happen
if the outer type is not whitelisted.
This commit avoids this gotcha by ensuring that all items end up in a module's
children list, and so will be code generated even if their parent is not
whitelisted.
Fixes #769
|
|
... Which is what Firefox uses right now.
|
|
And also its trait methods `is_named` and `as_named` into `is_template_param`
and `as_template_param` respectively.
These new names better reflect what the trait is about.
|
|
|
|
Like the ones seen in https://bugzilla.mozilla.org/show_bug.cgi?id=1365254#c22
|
|
Fixes #734
|
|
|
|
Fixes #755
|
|
|
|
Fixes #727
|
|
generation.
|
|
Const function can't have variables or blocks.
|
|
This should be good enough, following the pattern of anonymous items, and should
prevent most of the current noise in stylo updates.
Closes #620
Fixes #619
|
|
This commit flattens the nesting in `Bitfield::extend_ctor_impl`, as requested
in review, because it was getting pretty deep. Should be easier to read now.
|
|
This commit gives bindgen the ability to generate constructors for bitfield
allocation units. This enables more ergonomic use of struct literals for
bindings structs that contain bitfields.
Additionally, when we are generating unstable Rust, these constructors are
marked as const functions. This enables the creation of const binding structs
that contain bitfields.
|
|
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.
|
|
|
|
Otherwise you can't construct structs outside of the bindings file, which is
breaking.
Also, given the previous change was breaking and I didn't notice, I yanked
0.24.1.
|
|
This makes generated generic structs lifetime invariant, since we cannot know
the C++ type's true variance.
Fixes #506
|
|
|
|
Prefixes the clashing class method with class_ prefix
|
|
Fixes #654
|
|
Organizationally, it makes more sense.
|
|
The trait is all about accessing template parameters, and is also implemented
for things that are not template declarations or definitions, but do end up
using template parameters one way or another. The new name makes more sense.
|
|
We have a couple knobs to turn for item resolution, such as whether we keep
going through type references and type aliases. It makes sense to have a single,
easy place to configure these knobs.
|
|
|
|
|
|
|
|
Don't generate accessor methods for large bitfields
This fixes #570, by not generating accessor methods for large methods.
|
|
|
|
|
|
This commit defines a new set of assertion macros that are only checked in
testing/CI when the `testing_only_extra_assertions` feature is enabled. This
makes it so that *users* of bindgen that happen to be making a debug build don't
enable all these extra and expensive assertions.
Additionally, this removes the `testing_only_assert_no_dangling_items` feature,
and runs the assertions that were previously gated on that feature when the new
`testing_only_extra_assertions` feature is enabled.
|
|
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
|
|
|
|
|
|
|
|
|
|
|
|
```
warning: found non-foreign-function-safe member in struct marked #[repr(C)]: found zero-size struct in foreign module, consider adding a member to this struct
```
|
|
https://github.com/servo/rust-bindgen/pull/597#issuecomment-288006557
|
|
This commit makes bitfields' accessor codegen detect conflicting method names
and generate alternative, non-conflicting names instead.
|
|
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.
|
|
|
|
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`.
|
|
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
|
