Propagate derived traits for wrapper types#3327
Conversation
jsgf
force-pushed
the
fix-wrapper-derives
branch
9 times, most recently
from
bc2ab16 to
182e2cc
Compare
Rather than deriving a fixed set of traits for _BindgenOpaqueArray and similar wrapper types, derive the same traits that the types using them need. This avoids deriving unused traits, and also supports custom traits.
jsgf
force-pushed
the
fix-wrapper-derives
branch
from
182e2cc to
afb8740
Compare
emilio
left a comment
emilio
left a comment
There was a problem hiding this comment.
This seems like a significant amount of work for every generated struct... I wonder if instead we could just apply the general custom derive logic to the built-in types?
That'd be a bit more consistent with the non-built-in types (even though it requires configuration). It's a bit more explicit than automatically propagating it, too...
So, wdyt of just doing something like calling add_derives(... { "__BindgenBitfieldUnit", Struct }) etc when generating those types instead?
I think that'd be less special, cheaper, and equally powerful (or more? I can imagine wanting to derive a custom thingie for __BindgienBitfieldUnit or so only, perhaps?).
| *(core::ptr::addr_of!((*this).storage) as *const u8) | ||
| .offset(byte_index as isize) | ||
| *core::ptr::addr_of!((*this).storage).cast::<u8>() | ||
| .add(byte_index) |
There was a problem hiding this comment.
Some of these seem drive-by / probably from a separate patch? But looks good.
There was a problem hiding this comment.
Yeah I had several changes on the go, and I didn't completely separate them.
| @@ -2583,8 +2593,81 @@ impl CodeGenerator for CompInfo { | |||
| CanDerive::Manually; | |||
| } | |||
|
|
|||
| let mut derives: Vec<_> = derivable_traits.into(); | |||
| let mut derives = BTreeSet::new(); | |||
| let derivable: Vec<&'static str> = derivable_traits.into(); | |||
There was a problem hiding this comment.
Can we avoid this intermediate vec here and above?
I guess it really depends on how much you want to treat these internal structures as public interface. If you require users to explicitly derive types traits for them, then:
It seemed to me that it's better to treat them as internal implementation details, so they just inherit the traits their containing structures have. I've run into some cases where they won't derive (eg padding doesn't work with bytemuck's Pod trait), but so far that's been legit (Pod types aren't supposed to have padding anyway). |
2 participants
Rather than deriving a fixed set of traits for _BindgenOpaqueArray and similar wrapper types, derive the same traits that the types using them need. This avoids deriving unused traits, and also supports custom traits.