Oilpan: like Vector<T>, restrict Deque<T> to certain part objects.

Oilpan: like Vector<T>, restrict Deque<T> to certain part objects.

Impose the limitations put on Vector<T> on Deque<T> also. They're
both backed by a vector buffer where unused slots are zero'ed so as
to be safe when (conservatively) tracing the buffer contents or when
finalizing it.

In order to use a designated zero for cleared elements, certain
conditions have to be placed on the kinds of T we can allow when
T is a part object annotated with ALLOW_ONLY_INLINE_ALLOCATION().
Impose these statically by way of static_assert()s.

R=tkent,haraken
BUG=420515
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=202574

[sof, 2015-04-22 05:07:40]

sigbjornf@opera.com changed reviewers:
+ haraken@chromium.org, tkent@chromium.org

[sof, 2015-04-22 05:07:41]

Please take a look.

[haraken, 2015-04-22 05:29:40]

LGTM

https://codereview.chromium.org/1051853003/diff/1/Source/wtf/Deque.h
File Source/wtf/Deque.h (right):

https://codereview.chromium.org/1051853003/diff/1/Source/wtf/Deque.h#newcode232
Source/wtf/Deque.h:232: // destructor calls as long as the memory is zeroed.

Or can we add these static_assert to Vector::trace (or
HeapVectorBacking::trace)? Then we don't need to duplicate the static_asserts
between Vector and Deque.

[tkent, 2015-04-22 05:40:07]

lgtm

[sof, 2015-04-22 16:05:22]

https://codereview.chromium.org/1051853003/diff/1/Source/wtf/Deque.h
File Source/wtf/Deque.h (right):

https://codereview.chromium.org/1051853003/diff/1/Source/wtf/Deque.h#newcode232
Source/wtf/Deque.h:232: // destructor calls as long as the memory is zeroed.
On 2015/04/22 05:29:40, haraken wrote:
> 
> Or can we add these static_assert to Vector::trace (or
> HeapVectorBacking::trace)? Then we don't need to duplicate the static_asserts
> between Vector and Deque.

It makes some sense to keep it associated with the declaration of the collection
type, rather than where it is traced.

[sof, 2015-04-22 16:05:38]

The CQ bit was checked by sigbjornf@opera.com

[commit-bot: I haz the power, 2015-04-22 16:05:55]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1051853003/1

[haraken, 2015-04-22 16:07:15]

The CQ bit was unchecked by haraken@chromium.org

[haraken, 2015-04-22 16:07:46]

Let me stop the commit queue at the moment... I found more fundamental errors
about canInitializeWithMemset (I'll upload a CL soon).

[sof, 2015-09-20 18:57:10]

This one didn't quite make it in at the time.. shall we try to land it now?

[haraken, 2015-09-20 23:48:47]

LGTM

[sof, 2015-09-21 05:34:18]

The CQ bit was checked by sigbjornf@opera.com

[sof, 2015-09-21 05:34:18]

The patchset sent to the CQ was uploaded after l-g-t-m from tkent@chromium.org
Link to the patchset: https://codereview.chromium.org/1051853003/#ps20001
(title: "updated")

[commit-bot: I haz the power, 2015-09-21 05:34:29]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1051853003/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1051853003/20001

[commit-bot: I haz the power, 2015-09-21 05:38:48]

Committed patchset #2 (id:20001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=202574