Using operator= is not quite sound in presence of destructors and operator
overloading.
It's perfectly fine to assume that the left-hand-side of an operator= expression
is valid memory, however we're using uninitialized memory here, that may not be
the case.
Use placement new to properly construct tagged unions. I don't need this with
any urgency, but it's the right thing to do in presence of complex types, and
the current code seems a bomb waiting to explode :)
This fixes one of my pet-peeves. Without this patch, I need to add them manually
using the raw body stuff, or along the code that accesses the struct member,
none of those being ideal.
Boris hit this because he used #[repr(C)] instead of #[repr(u8)].
We were incorrectly writing the generic arguments twice for those.
I missed this difference in #219.
Fixes#225.
Going to need this if I ever aim to generate TransformOperation bindings and
remove a bunch of slow and ugly Gecko code:
https://searchfox.org/mozilla-central/rev/80ac71c1c54af788b32e851192dfd2de2ec18e18/servo/components/style/values/generics/transform.rs#189
With the caveat that I'll need to remove the options, but I can manage to do
that.
This also fixes a bunch of renaming bugs that I found while at it.
This patch has the gotcha that we need to remove the assertion of no-underscores
in mangled names... But I think it should be fine, and I'd rather not do a more
breaking change.
You can generate conflicting names in C using enum variants with the same name
as a struct regardless, for example, so I don't think this is terribly
important.
Emilio Cobos Álvarez
Dan Robertson