Oilpan: fix build after r197063, move HitTestCache to the heap.

Source/core/layout/HitTestResult.h

Index: Source/core/layout/HitTestResult.h
diff --git a/Source/core/layout/HitTestResult.h b/Source/core/layout/HitTestResult.h
index dea3ffbedf7882a27a437861d505c28e3182bfcf..5cb8f1ff31d8f8a79924b368c14c5ae553d13225 100644
--- a/Source/core/layout/HitTestResult.h
+++ b/Source/core/layout/HitTestResult.h
@@ -34,6 +34,7 @@
 #include "wtf/ListHashSet.h"
 #include "wtf/OwnPtr.h"
 #include "wtf/RefPtr.h"
+#include "wtf/VectorTraits.h"
 
 namespace blink {
 
@@ -172,4 +173,6 @@ private:
 
 } // namespace blink
 
+WTF_ALLOW_INIT_WITH_MEM_FUNCTIONS(blink::HitTestResult);

[haraken, 2015/06/13 07:12:21]

The default constructor of blink::HitTestResult is setting  m_hitTestRequest to
HitTestRequest::ReadOnly|HitTestRequest::Active, but is it ok to initialize it
with memset?

[sof, 2015/06/13 12:30:31]

For the one use of HitTestResult in a vector (HitTestCache), it will be. The
alternative is to add a wrapper (heap) object indirection, which is somewhat
tedious.

[sof, 2015/06/13 17:00:03]

Is the HeapVector<> restriction accurate, or is it merely reusing
canInitializeWithMemset for convenience?

i.e., canInitializeWithMemset is used to determine if unused slots can be
cleared with memset(). So that we can guarantee that tracing those slots won't
run into trouble. Unused slots are otherwise not observable, so if they
represent valid objects or not, isn't relevant. Slots will otherwise be
initalize()d correctly.

+
 #endif // HitTestResult_h