Oilpan: Move CSSAnimationData and CSSAnimationDataList to oilpan's heap

Oilpan: Move CSSAnimationData and CSSAnimationDataList to oilpan's heap

BUG=341032
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=169945

[haraken, 2014-03-25 12:47:37]

PTAL

https://codereview.chromium.org/207683005/diff/60001/Source/core/rendering/st...
File Source/core/rendering/style/StyleRareNonInheritedData.h (left):

https://codereview.chromium.org/207683005/diff/60001/Source/core/rendering/st...
Source/core/rendering/style/StyleRareNonInheritedData.h:125:
OwnPtr<CSSAnimationDataList> m_transitions;

At first I forgot to change this OwnPtr to OwnPtrWillBePersistent. However, it
didn't cause a compile error and I couldn't notice it until seeing some layout
tests failed.

C++ experts: What's the easiest way to cause a compile error when OwnPtr is used
for a GarbageCollected class?

[zerny-chromium, 2014-03-25 13:01:33]

On 2014/03/25 12:47:37, haraken wrote:
> PTAL
> 
>
https://codereview.chromium.org/207683005/diff/60001/Source/core/rendering/st...
> File Source/core/rendering/style/StyleRareNonInheritedData.h (left):
> 
>
https://codereview.chromium.org/207683005/diff/60001/Source/core/rendering/st...
> Source/core/rendering/style/StyleRareNonInheritedData.h:125:
> OwnPtr<CSSAnimationDataList> m_transitions;
> 
> At first I forgot to change this OwnPtr to OwnPtrWillBePersistent. However, it
> didn't cause a compile error and I couldn't notice it until seeing some layout
> tests failed.
> 
> C++ experts: What's the easiest way to cause a compile error when OwnPtr is
used
> for a GarbageCollected class?

If it is an OwnPtr<T> member of some struct/class, then the clang plugin should
give you an error if T is GC allocated (ie, GC, GCFinalized, RefCountedGC,
GCMixin, and heap allocated collections). If the plugin does not issue an error,
that is a failure of the plugin and you can file a bug on the plugin or tell me.

[sof, 2014-03-25 13:14:42]

https://codereview.chromium.org/207683005/diff/60001/Source/core/animation/cs...
File Source/core/animation/css/CSSAnimationData.h (right):

https://codereview.chromium.org/207683005/diff/60001/Source/core/animation/cs...
Source/core/animation/css/CSSAnimationData.h:38: class CSSAnimationData : public
RefCountedWillBeGarbageCollectedFinalized<CSSAnimationData> {
Add FINAL?

https://codereview.chromium.org/207683005/diff/60001/Source/core/animation/cs...
File Source/core/animation/css/CSSAnimationDataList.h (right):

https://codereview.chromium.org/207683005/diff/60001/Source/core/animation/cs...
Source/core/animation/css/CSSAnimationDataList.h:34: class CSSAnimationDataList
: public NoBaseWillBeGarbageCollected<CSSAnimationDataList> {
Worth adding FINAL?

[wibling-chromium, 2014-03-25 13:19:56]

lgtm

[haraken, 2014-03-25 13:26:28]

Thanks for review!

https://codereview.chromium.org/207683005/diff/60001/Source/core/animation/cs...
File Source/core/animation/css/CSSAnimationData.h (right):

https://codereview.chromium.org/207683005/diff/60001/Source/core/animation/cs...
Source/core/animation/css/CSSAnimationData.h:38: class CSSAnimationData : public
RefCountedWillBeGarbageCollectedFinalized<CSSAnimationData> {
On 2014/03/25 13:14:42, sof wrote:
> Add FINAL?

Done.

https://codereview.chromium.org/207683005/diff/60001/Source/core/animation/cs...
File Source/core/animation/css/CSSAnimationDataList.h (right):

https://codereview.chromium.org/207683005/diff/60001/Source/core/animation/cs...
Source/core/animation/css/CSSAnimationDataList.h:34: class CSSAnimationDataList
: public NoBaseWillBeGarbageCollected<CSSAnimationDataList> {
On 2014/03/25 13:14:42, sof wrote:
> Worth adding FINAL?

Done.

[haraken, 2014-03-25 13:26:32]

The CQ bit was checked by haraken@chromium.org

[commit-bot: I haz the power, 2014-03-25 13:26:34]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/haraken@chromium.org/207683005/50007

[haraken, 2014-03-25 13:28:35]

On 2014/03/25 13:01:33, zerny-chromium wrote:
> On 2014/03/25 12:47:37, haraken wrote:
> > PTAL
> > 
> >
>
https://codereview.chromium.org/207683005/diff/60001/Source/core/rendering/st...
> > File Source/core/rendering/style/StyleRareNonInheritedData.h (left):
> > 
> >
>
https://codereview.chromium.org/207683005/diff/60001/Source/core/rendering/st...
> > Source/core/rendering/style/StyleRareNonInheritedData.h:125:
> > OwnPtr<CSSAnimationDataList> m_transitions;
> > 
> > At first I forgot to change this OwnPtr to OwnPtrWillBePersistent. However,
it
> > didn't cause a compile error and I couldn't notice it until seeing some
layout
> > tests failed.
> > 
> > C++ experts: What's the easiest way to cause a compile error when OwnPtr is
> used
> > for a GarbageCollected class?
> 
> If it is an OwnPtr<T> member of some struct/class, then the clang plugin
should
> give you an error if T is GC allocated (ie, GC, GCFinalized, RefCountedGC,
> GCMixin, and heap allocated collections). If the plugin does not issue an
error,
> that is a failure of the plugin and you can file a bug on the plugin or tell
me.

I agree that the plugin can catch the error, but it would be better if we can
catch it in compile time as well.

[commit-bot: I haz the power, 2014-03-25 14:32:47]

Change committed as 169945