Oilpan: Remove most WillBe types from the code base

Oilpan: Remove most WillBe types from the code base

Now that Oilpan is shipped, we can remove WillBe types from the code base.
This CL replaces XWillBeY with Y.

This CL is created mechanically by a perl script (http://pastebin.com/ERruijzQ)
except the following points:

- Removed bindings/tests/idls/core/TestInterfaceWillBeGarbageCollected.idl.
- Removed duplicated toMemberNativeArray in V8Binding.h.
- Removed unnecessary .get() in ImageBitmapFactories.cpp,
XMLHttpRequest.cpp, MessageEvent.cpp and CanvasRenderingContext2D.cpp.

BUG=585328
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel
NOTRY=true

[haraken, 2016-02-09 04:35:33]

haraken@chromium.org changed reviewers:
+ oilpan-reviews@chromium.org, sigbjornf@opera.com

[haraken, 2016-02-09 04:35:43]

PTAL

I'm planning to land this CL on Feb 12 after sending a PSA to blink-dev@.

https://codereview.chromium.org/1686483002/diff/1/third_party/WebKit/Source/w...
File third_party/WebKit/Source/willbe.pl (right):

https://codereview.chromium.org/1686483002/diff/1/third_party/WebKit/Source/w...
third_party/WebKit/Source/willbe.pl:1: use strict;

I will remove this script before landing this CL.

[sof, 2016-02-09 06:14:09]

Unbelievable :-)

Do you think you could tweak the script to generate
  
  Foo* foo = Foo::create();

from

  RefPtrWillBeRawPtr<Foo> foo = Foo::create();

? It would save a followup pass.

[sof, 2016-02-09 06:14:16]

Unbelievable :-)

Do you think you could tweak the script to generate
  
  Foo* foo = Foo::create();

from

  RefPtrWillBeRawPtr<Foo> foo = Foo::create();

? It would save a followup pass.

[dcheng, 2016-02-09 06:18:32]

On 2016/02/09 at 06:14:16, sigbjornf wrote:
> Unbelievable :-)
> 
> Do you think you could tweak the script to generate
>   
>   Foo* foo = Foo::create();
> 
> from
> 
>   RefPtrWillBeRawPtr<Foo> foo = Foo::create();
> 
> ? It would save a followup pass.

This isn't necessarily a safe transformation, if there are calls to ".get".

[haraken, 2016-02-09 06:18:54]

On 2016/02/09 06:14:16, sof wrote:
> Unbelievable :-)
> 
> Do you think you could tweak the script to generate
>   
>   Foo* foo = Foo::create();
> 
> from
> 
>   RefPtrWillBeRawPtr<Foo> foo = Foo::create();
> 
> ? It would save a followup pass.

I tried that, but in that case I need to remove a ton of .get()'s at the same
time. So I've decided to defer the RawPtr<T> => T* replacement to follow-up
patches :)

[sof, 2016-02-09 06:25:30]

On 2016/02/09 06:18:32, dcheng wrote:
> On 2016/02/09 at 06:14:16, sigbjornf wrote:
> > Unbelievable :-)
> > 
> > Do you think you could tweak the script to generate
> >   
> >   Foo* foo = Foo::create();
> > 
> > from
> > 
> >   RefPtrWillBeRawPtr<Foo> foo = Foo::create();
> > 
> > ? It would save a followup pass.
> 
> This isn't necessarily a safe transformation, if there are calls to ".get".

What's unsafe about the above? e.g. there's half a dozen of them here in this
file https://codereview.chromium.org/1686483002/patch/10001/5471638548119552

[sof, 2016-02-09 06:35:37]

On 2016/02/09 06:18:54, haraken wrote:
> On 2016/02/09 06:14:16, sof wrote:
> > Unbelievable :-)
> > 
> > Do you think you could tweak the script to generate
> >   
> >   Foo* foo = Foo::create();
> > 
> > from
> > 
> >   RefPtrWillBeRawPtr<Foo> foo = Foo::create();
> > 
> > ? It would save a followup pass.
> 
> I tried that, but in that case I need to remove a ton of .get()'s at the same
> time. So I've decided to defer the RawPtr<T> => T* replacement to follow-up
> patches :)

Why would you use get() to bind a RefPtr<> stack allocation? I'm not convinced
this is a common problem, in general (not just create() constructions.)

[sof, 2016-02-09 06:57:18]

On 2016/02/09 06:35:37, sof wrote:
> On 2016/02/09 06:18:54, haraken wrote:
> > On 2016/02/09 06:14:16, sof wrote:
> > > Unbelievable :-)
> > > 
> > > Do you think you could tweak the script to generate
> > >   
> > >   Foo* foo = Foo::create();
> > > 
> > > from
> > > 
> > >   RefPtrWillBeRawPtr<Foo> foo = Foo::create();
> > > 
> > > ? It would save a followup pass.
> > 
> > I tried that, but in that case I need to remove a ton of .get()'s at the
same
> > time. So I've decided to defer the RawPtr<T> => T* replacement to follow-up
> > patches :)
> 
> Why would you use get() to bind a RefPtr<> stack allocation? I'm not convinced
> this is a common problem, in general (not just create() constructions.)

Hmm, release() usage would be more of a problem. Alright, two passes makes
sense.

[sof, 2016-02-09 15:45:46]

Went through ~30% of the files, changes all regular. Respective owners are
welcome to have a look through, but purely a mechanical change.

I'm not confident if the removal of the "WillBe" support in the IDL compiler is
in a sane state, so if you can look at doing a more complete purge job there,
that'd be good (But if it works & bindings test pass, it can wait.)

Why didn't you remove the WillBe macros from platform/heap/Handle.h here -- are
there still uses left?

https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
File third_party/WebKit/Source/bindings/core/v8/V8ErrorHandler.h (right):

https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/core/v8/V8ErrorHandler.h:46:
RawPtr<V8ErrorHandler> eventListener = (new V8ErrorHandler(isInline,
scriptState));
adoptPtrWillBeNoop(A) => A instead?

https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
File
third_party/WebKit/Source/bindings/scripts/compute_interfaces_info_overall.py
(right):

https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/scripts/compute_interfaces_info_overall.py:95:
'GarbageCollected',
Duplicate.

https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/scripts/compute_interfaces_info_overall.py:189:
if 'GarbageCollected' in inherited_extended_attributes:
will_be_garbage_* no longer needed, right?

https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
File third_party/WebKit/Source/bindings/scripts/v8_callback_interface.py
(right):

https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/scripts/v8_callback_interface.py:66: # Pass
containers and dictionaries to callback method by const reference rather than by
value
duplicate

https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
File third_party/WebKit/Source/bindings/scripts/v8_types.py (right):

https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/scripts/v8_types.py:307:
IdlType.will_be_garbage_collected_types = set()
Remove?

https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/scripts/v8_types.py:321: return
'WillBeGarbageCollectedObject'
Why keep this?

https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
File third_party/WebKit/Source/bindings/scripts/v8_utilities.py (right):

https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/scripts/v8_utilities.py:326: #
[GarbageCollected], [GarbageCollected]
More duplication.

https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
File
third_party/WebKit/Source/bindings/tests/idls/core/TestCallbackInterface.idl
(right):

https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/tests/idls/core/TestCallbackInterface.idl:39:
// [GarbageCollected]
Just remove this right away?

https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
File third_party/WebKit/Source/bindings/tests/idls/core/TestDictionary.idl
(right):

https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/tests/idls/core/TestDictionary.idl:17:
TestInterfaceGarbageCollected testInterfaceGarbageCollectedMember;
duplication w/ above - is that legal to declare?

https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
File third_party/WebKit/Source/bindings/tests/results/core/V8TestDictionary.cpp
(right):

https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
third_party/WebKit/Source/bindings/tests/results/core/V8TestDictionary.cpp:20:
#include "bindings/core/v8/V8TestInterfaceGarbageCollected.h"
duplicate

https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/animation/CSSLengthInterpolationType.cpp
(right):

https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/animation/CSSLengthInterpolationType.cpp:285:
RawPtr<CSSPrimitiveValue> result;
unused (not worth fixing here.)

https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
File third_party/WebKit/Source/willbe.pl (right):

https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
third_party/WebKit/Source/willbe.pl:1: use strict;
Intentional inclusion of this file?

[haraken, 2016-02-10 01:50:16]

Thanks for looking at such a giant CL!

On 2016/02/09 15:45:46, sof wrote:
> Went through ~30% of the files, changes all regular. Respective owners are
> welcome to have a look through, but purely a mechanical change.
> 
> I'm not confident if the removal of the "WillBe" support in the IDL compiler
is
> in a sane state, so if you can look at doing a more complete purge job there,
> that'd be good (But if it works & bindings test pass, it can wait.)

Nice catch -- I reverted most changes in the IDL comipler. I'll defer the
changes to follow-up CLs.

> 
> Why didn't you remove the WillBe macros from platform/heap/Handle.h here --
are
> there still uses left?

I'm planning to defer it to follow-up CLs.

The point is that I want to make this CL as (mechanical changes + \epsilon).
Given that this CL will conflict with many CLs on ToT, I'll need to repeat
rebase the CL many times until actually landing it. So I want to minimize the
\epsilon as much as possible :)

> 
>
https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/bindings/core/v8/V8ErrorHandler.h (right):
> 
>
https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
> third_party/WebKit/Source/bindings/core/v8/V8ErrorHandler.h:46:
> RawPtr<V8ErrorHandler> eventListener = (new V8ErrorHandler(isInline,
> scriptState));
> adoptPtrWillBeNoop(A) => A instead?
> 
>
https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
> File
> third_party/WebKit/Source/bindings/scripts/compute_interfaces_info_overall.py
> (right):
> 
>
https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
>
third_party/WebKit/Source/bindings/scripts/compute_interfaces_info_overall.py:95:
> 'GarbageCollected',
> Duplicate.
> 
>
https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
>
third_party/WebKit/Source/bindings/scripts/compute_interfaces_info_overall.py:189:
> if 'GarbageCollected' in inherited_extended_attributes:
> will_be_garbage_* no longer needed, right?
> 
>
https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/bindings/scripts/v8_callback_interface.py
> (right):
> 
>
https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
> third_party/WebKit/Source/bindings/scripts/v8_callback_interface.py:66: # Pass
> containers and dictionaries to callback method by const reference rather than
by
> value
> duplicate
> 
>
https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/bindings/scripts/v8_types.py (right):
> 
>
https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
> third_party/WebKit/Source/bindings/scripts/v8_types.py:307:
> IdlType.will_be_garbage_collected_types = set()
> Remove?
> 
>
https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
> third_party/WebKit/Source/bindings/scripts/v8_types.py:321: return
> 'WillBeGarbageCollectedObject'
> Why keep this?
> 
>
https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/bindings/scripts/v8_utilities.py (right):
> 
>
https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
> third_party/WebKit/Source/bindings/scripts/v8_utilities.py:326: #
> [GarbageCollected], [GarbageCollected]
> More duplication.
> 
>
https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
> File
> third_party/WebKit/Source/bindings/tests/idls/core/TestCallbackInterface.idl
> (right):
> 
>
https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
>
third_party/WebKit/Source/bindings/tests/idls/core/TestCallbackInterface.idl:39:
> // [GarbageCollected]
> Just remove this right away?
> 
>
https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/bindings/tests/idls/core/TestDictionary.idl
> (right):
> 
>
https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
> third_party/WebKit/Source/bindings/tests/idls/core/TestDictionary.idl:17:
> TestInterfaceGarbageCollected testInterfaceGarbageCollectedMember;
> duplication w/ above - is that legal to declare?
> 
>
https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
> File
third_party/WebKit/Source/bindings/tests/results/core/V8TestDictionary.cpp
> (right):
> 
>
https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
> third_party/WebKit/Source/bindings/tests/results/core/V8TestDictionary.cpp:20:
> #include "bindings/core/v8/V8TestInterfaceGarbageCollected.h"
> duplicate
> 
>
https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/core/animation/CSSLengthInterpolationType.cpp
> (right):
> 
>
https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
> third_party/WebKit/Source/core/animation/CSSLengthInterpolationType.cpp:285:
> RawPtr<CSSPrimitiveValue> result;
> unused (not worth fixing here.)
> 
>
https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/willbe.pl (right):
> 
>
https://codereview.chromium.org/1686483002/diff/10001/third_party/WebKit/Sour...
> third_party/WebKit/Source/willbe.pl:1: use strict;
> Intentional inclusion of this file?

[haraken, 2016-02-10 02:02:28]

Description was changed from

==========
Oilpan: Remove most WillBe types from the code base

Now that Oilpan is shipped, we can remove WillBe types from the code base.
This CL replaces XWillBeY with Y.

This CL is created mechanically by a perl script (http://pastebin.com/ERruijzQ)
except the following points:

- Removed bindings/tests/idls/core/TestInterfaceWillBeGarbageCollected.idl.
- Removed duplicated toMemberNativeArray in V8Binding.h.
- Removed unnecessary .get() in ImageBitmapFactories.cpp, XMLHttpRequest.cpp,
MessageEvent.cpp and CanvasRenderingContext2D.cpp.

BUG=585328
==========

to

==========
Oilpan: Remove most WillBe types from the code base

Now that Oilpan is shipped, we can remove WillBe types from the code base.
This CL replaces XWillBeY with Y.

This CL is created mechanically by a perl script (http://pastebin.com/ERruijzQ)
except the following points:

- Removed bindings/tests/idls/core/TestInterfaceWillBeGarbageCollected.idl.
- Removed duplicated toMemberNativeArray in V8Binding.h.
- Removed unnecessary .get() in ImageBitmapFactories.cpp, XMLHttpRequest.cpp,
MessageEvent.cpp and CanvasRenderingContext2D.cpp.

BUG=585328
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[esprehn, 2016-02-11 08:17:20]

Description was changed from

==========
Oilpan: Remove most WillBe types from the code base

Now that Oilpan is shipped, we can remove WillBe types from the code base.
This CL replaces XWillBeY with Y.

This CL is created mechanically by a perl script (http://pastebin.com/ERruijzQ)
except the following points:

- Removed bindings/tests/idls/core/TestInterfaceWillBeGarbageCollected.idl.
- Removed duplicated toMemberNativeArray in V8Binding.h.
- Removed unnecessary .get() in ImageBitmapFactories.cpp, XMLHttpRequest.cpp,
MessageEvent.cpp and CanvasRenderingContext2D.cpp.

BUG=585328
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
Oilpan: Remove most WillBe types from the code base

Now that Oilpan is shipped, we can remove WillBe types from the code base.
This CL replaces XWillBeY with Y.

This CL is created mechanically by a perl script (http://pastebin.com/ERruijzQ)
except the following points:

- Removed bindings/tests/idls/core/TestInterfaceWillBeGarbageCollected.idl.
- Removed duplicated toMemberNativeArray in V8Binding.h.
- Removed unnecessary .get() in ImageBitmapFactories.cpp,
XMLHttpRequest.cpp, MessageEvent.cpp and CanvasRenderingContext2D.cpp.

BUG=585328
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[sof, 2016-02-11 08:32:44]

On 2016/02/10 01:50:16, haraken wrote:
>
..
> 
> > 
> > Why didn't you remove the WillBe macros from platform/heap/Handle.h here --
> are
> > there still uses left?
> 
> I'm planning to defer it to follow-up CLs.
> 
> The point is that I want to make this CL as (mechanical changes + \epsilon).
> Given that this CL will conflict with many CLs on ToT, I'll need to repeat
> rebase the CL many times until actually landing it. So I want to minimize the
> \epsilon as much as possible :)
> 

That's totally fine, but is this change complete wrt WillBe removal? (I haven't
"git cl patch"ed the CL to check.)

[haraken, 2016-02-11 09:42:38]

On 2016/02/11 08:32:44, sof wrote:
> On 2016/02/10 01:50:16, haraken wrote:
> >
> ..
> > 
> > > 
> > > Why didn't you remove the WillBe macros from platform/heap/Handle.h here
--
> > are
> > > there still uses left?
> > 
> > I'm planning to defer it to follow-up CLs.
> > 
> > The point is that I want to make this CL as (mechanical changes + \epsilon).
> > Given that this CL will conflict with many CLs on ToT, I'll need to repeat
> > rebase the CL many times until actually landing it. So I want to minimize
the
> > \epsilon as much as possible :)
> > 
> 
> That's totally fine, but is this change complete wrt WillBe removal? (I
haven't
> "git cl patch"ed the CL to check.)

Not complete but 99.9% complete (which is the intention of this CL). For
example, DEFINE_STATIC_REF_WILL_BE_PERSISTENT will be removed in a follow-up CL.

[haraken, 2016-02-11 11:50:52]

Rebased the CL with ToT.

[sof, 2016-02-11 12:39:29]

lgtm, but api owner approval clearly needed to get this one past CQ.

[haraken, 2016-02-11 14:02:08]

haraken@chromium.org changed reviewers:
+ tkent@chromium.org

[haraken, 2016-02-11 14:02:13]

tkent-san: Would you take a quick look at this CL as an API owner?

[tkent, 2016-02-12 00:02:51]

rs lgtm.

In general, such huge code cleanup CL should be landed just before making a new
milestone branch in order to reduce merge pain. However probably you think
resolving the WillBe pain is more important than increasing the merge pain.  So,
it's ok to land this.

[haraken, 2016-02-12 00:32:06]

The CQ bit was checked by haraken@chromium.org

[haraken, 2016-02-12 00:32:11]

The patchset sent to the CQ was uploaded after l-g-t-m from sigbjornf@opera.com,
tkent@chromium.org
Link to the patchset: https://codereview.chromium.org/1686483002/#ps50001
(title: " ")

[commit-bot: I haz the power, 2016-02-12 00:34:38]

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

[tkent, 2016-02-12 01:36:32]

The CQ bit was unchecked by tkent@chromium.org

[tkent, 2016-02-12 01:37:34]

On 2016/02/12 at 01:36:32, tkent wrote:
> The CQ bit was unchecked by tkent@chromium.org

A concern was raised in blink-dev.

[haraken, 2016-03-30 08:18:13]

No concern was raised on the blink-dev thread, let me land this CL.

[haraken, 2016-03-30 08:20:22]

The CQ bit was checked by haraken@chromium.org

[haraken, 2016-03-30 08:20:30]

The patchset sent to the CQ was uploaded after l-g-t-m from tkent@chromium.org,
sigbjornf@opera.com
Link to the patchset: https://codereview.chromium.org/1686483002/#ps60001
(title: " ")

[commit-bot: I haz the power, 2016-03-30 08:20:57]

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

[tkent, 2016-03-30 08:25:55]

Did you remove non-oilpan buildbots before landing this?

[haraken, 2016-03-30 08:29:04]

On 2016/03/30 08:25:55, tkent wrote:
> Did you remove non-oilpan buildbots before landing this?

No. Why do we need to remove non-oilpan bots first? After landing this CL, both
default bots and non-oilpan bots run oilpan builds, which seems just fine?

[tkent, 2016-03-30 08:47:04]

> No. Why do we need to remove non-oilpan bots first? After landing this CL,
both default bots and non-oilpan bots run oilpan builds, which seems just fine?

Is this CL buildable without ENABLE(OILPAN)? If so, no problem.

[commit-bot: I haz the power, 2016-03-30 08:47:16]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-03-30 08:47:25]

Try jobs failed on following builders:
  linux_chromium_chromeos_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[haraken, 2016-03-30 10:51:39]

The CQ bit was checked by haraken@chromium.org

[haraken, 2016-03-30 10:51:46]

The patchset sent to the CQ was uploaded after l-g-t-m from tkent@chromium.org,
sigbjornf@opera.com
Link to the patchset: https://codereview.chromium.org/1686483002/#ps70001
(title: " ")

[commit-bot: I haz the power, 2016-03-30 10:52:13]

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

[commit-bot: I haz the power, 2016-03-30 11:40:05]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-03-30 11:40:15]

Try jobs failed on following builders:
  linux_blink_oilpan_rel on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_blink_oil...)

[haraken, 2016-03-30 12:13:44]

On 2016/03/30 08:47:04, tkent wrote:
> > No. Why do we need to remove non-oilpan bots first? After landing this CL,
> both default bots and non-oilpan bots run oilpan builds, which seems just
fine?
> 
> Is this CL buildable without ENABLE(OILPAN)? If so, no problem.

Ah, you're right. I need to set ENABLE_OILPAN=1 regardless of the value of
enable_oilpan. Fixed.

(My plan is to unconditionally set ENABLE_OILPAN=1 and then remove all oilpan
bots from the Chrome infra.)

[haraken, 2016-03-30 12:49:42]

The CQ bit was checked by haraken@chromium.org

[haraken, 2016-03-30 12:49:49]

The patchset sent to the CQ was uploaded after l-g-t-m from tkent@chromium.org,
sigbjornf@opera.com
Link to the patchset: https://codereview.chromium.org/1686483002/#ps80001
(title: " ")

[commit-bot: I haz the power, 2016-03-30 12:50:10]

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

[Sergiy Byelozyorov, 2016-03-30 15:54:08]

The CQ bit was unchecked by sergiyb@chromium.org

[commit-bot: I haz the power, 2016-03-30 15:54:33]

The CQ bit was unchecked by commit-bot@chromium.org

[haraken, 2016-03-30 23:09:25]

The CQ bit was checked by haraken@chromium.org

[commit-bot: I haz the power, 2016-03-30 23:10:15]

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

[haraken, 2016-03-31 00:57:36]

Description was changed from

==========
Oilpan: Remove most WillBe types from the code base

Now that Oilpan is shipped, we can remove WillBe types from the code base.
This CL replaces XWillBeY with Y.

This CL is created mechanically by a perl script (http://pastebin.com/ERruijzQ)
except the following points:

- Removed bindings/tests/idls/core/TestInterfaceWillBeGarbageCollected.idl.
- Removed duplicated toMemberNativeArray in V8Binding.h.
- Removed unnecessary .get() in ImageBitmapFactories.cpp,
XMLHttpRequest.cpp, MessageEvent.cpp and CanvasRenderingContext2D.cpp.

BUG=585328
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
Oilpan: Remove most WillBe types from the code base

Now that Oilpan is shipped, we can remove WillBe types from the code base.
This CL replaces XWillBeY with Y.

This CL is created mechanically by a perl script (http://pastebin.com/ERruijzQ)
except the following points:

- Removed bindings/tests/idls/core/TestInterfaceWillBeGarbageCollected.idl.
- Removed duplicated toMemberNativeArray in V8Binding.h.
- Removed unnecessary .get() in ImageBitmapFactories.cpp,
XMLHttpRequest.cpp, MessageEvent.cpp and CanvasRenderingContext2D.cpp.

BUG=585328
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel
NOTRY=true
==========

[haraken, 2016-03-31 01:03:32]

The CQ bit was unchecked by haraken@chromium.org

[commit-bot: I haz the power, 2016-03-31 01:03:48]

The CQ bit was unchecked by commit-bot@chromium.org

[haraken, 2016-03-31 01:14:32]

The CQ bit was checked by haraken@chromium.org

[commit-bot: I haz the power, 2016-03-31 01:15:10]

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

[haraken, 2016-03-31 02:21:08]

I noticed that our infra is not robust enough to land a 13000 LOC change. Let me
split the CL into pieces.

[tkent, 2016-03-31 05:36:51]

The CQ bit was unchecked by tkent@chromium.org