Oilpan: fix build after r177450.

Oilpan: fix build after r177450.

Update ScriptPromise tests to be Oilpan compatible.

R=haraken@chromium.org
BUG=363967
NOTRY=true

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

[sof, 2014-07-03 09:03:24]

Please take a look.

[haraken, 2014-07-03 09:07:41]

LGTM. Sorry I reviewed the CL.

[sof, 2014-07-03 09:10:25]

On 2014/07/03 09:07:41, haraken wrote:
> LGTM. Sorry I reviewed the CL.

Thanks - if it passes compilation & unit tests for a reduced set of targets, I
will NOTRY it.

[sof, 2014-07-03 09:47:29]

On 2014/07/03 09:10:25, sof wrote:
> On 2014/07/03 09:07:41, haraken wrote:
> > LGTM. Sorry I reviewed the CL.
> 
> Thanks - if it passes compilation & unit tests for a reduced set of targets, I
> will NOTRY it.

Had to move ScriptPromisePropertyBase to the heap also to make this work -
ptaal?

[sof, 2014-07-03 10:01:12]

The CQ bit was checked by sigbjornf@opera.com

[commit-bot: I haz the power, 2014-07-03 10:01:29]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/sigbjornf@opera.com/367263004/20001

[commit-bot: I haz the power, 2014-07-03 10:01:52]

Change committed as 177463

[haraken, 2014-07-03 10:27:23]

still LGTM

[dominicc (has gone to gerrit), 2014-07-03 23:56:44]

On 2014/07/03 10:27:23, haraken wrote:
> still LGTM

Um... what about tracing the resolved and rejected values?

There was feedback on this review that because this is a templatized type, it
shouldn't be Oilpanified yet? https://codereview.chromium.org/361863003

[haraken, 2014-07-04 00:52:01]

On 2014/07/03 23:56:44, dominicc wrote:
> On 2014/07/03 10:27:23, haraken wrote:
> > still LGTM
> 
> Um... what about tracing the resolved and rejected values?
> 
> There was feedback on this review that because this is a templatized type, it
> shouldn't be Oilpanified yet? https://codereview.chromium.org/361863003

Sorry, I was confused. I was missing the fact that oilpaned objects can be
passed to HolderType. Also I was missing the fact that oilpaned objects can be
also passed to ResolvedType and RejectedType (but currently not by accident).

So I think you're right that we need to trace all of m_holder, m_resolved and
m_rejected.

Once someone passes not-yet-oilpaned objects to
HolderType/ResolvedType/RejectedType, it might cause errors, but let's worry
about it when it actually happens.