Oilpan: IDL union objects should be put in HeapVector

Source/bindings/templates/union.h

Index: Source/bindings/templates/union.h
diff --git a/Source/bindings/templates/union.h b/Source/bindings/templates/union.h
index 497846bc30da6b7236e64e66679615a78fc64fad..79e94e7c70efe08b42e5b229448e3d399f97d7e0 100644
--- a/Source/bindings/templates/union.h
+++ b/Source/bindings/templates/union.h
@@ -89,4 +89,8 @@ public:
 {% endfor %}
 } // namespace blink
 
+{% for container in containers %}
+WTF_ALLOW_MOVE_AND_INIT_WITH_MEM_FUNCTIONS(blink::{{container.cpp_class}});

[haraken, 2015/05/01 14:58:13]

bashi-san@: Is it correct to set canInitializeWithMemset=true for IDL union
objects?

[Jens Widell, 2015/05/04 14:02:18]

I'm guessing it would work in practice, but it's technically wrong in some
cases: Dictionary, generated dictionary types, and Nullable<>.

Dictionary has a default constructor that sets m_exceptionState to a non-null
pointer value. While we do assert that m_exceptionState isn't null in some
member functions, those asserts can only be reached if the dictionary wraps an
object value, which it wouldn't (the m_options handle would be empty). And
besides, the Dictionary member in the union wouldn't be used either, since the
union would have no value set, so none of the member functions of the Dictionary
object should be called (except the destructor and assignment operator, which
are both fine).

Generated dictionary types have default constructors that can set various
default member values, but again, as a member in an empty union, such an
incorrectly initialized object shouldn't be used. The member types are the same
as in unions, so this discussion applies recursively.

Nullable<> has a default constructor that sets m_isNull to true. Same here
though, this shouldn't matter since such a union member shouldn't be used.

Other typical union members are primitives, various pointer types (RefPtr,
Member, String) that are definitely safe, and  Vector<>/HeapVector<>. Vectors
look safe to me, but I don't know if they're actually declared to have
canInitializeWithMemset=true.

So, in summary: since memset()-initialized union members shouldn't be accessed,
only their destructors and assignment operators really matter, and those all
look safe to me.

[bashi, 2015/05/07 23:59:23]

Thanks Jens for detailed explanation! Given above, I think it would work in
practice. I'd be happy if there is another workaround, but I think this is an
acceptable approach.

+{% endfor %}
+
 #endif // {{macro_guard}}