Oilpan: fix build after r351868.

Oilpan: fix build after r351868.

We do not have compiler support for traceable Oilpan heap references,
hence undo the Member<> to ref conversion that r351868 made.

TBR=oilpan-reviews
BUG=
NOTRY=true

Committed: https://crrev.com/1c2a93f3cdcf4673299a3c6c4b6b8b79c504f088
Cr-Commit-Position: refs/heads/master@{#351887}

[sof, 2015-10-01 21:11:03]

sigbjornf@opera.com changed reviewers:
+ wangxianzhu@chromium.org

[sof, 2015-10-01 21:11:08]

The CQ bit was checked by sigbjornf@opera.com

[commit-bot: I haz the power, 2015-10-01 21:11:42]

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

[commit-bot: I haz the power, 2015-10-01 21:18:39]

Committed patchset #1 (id:1)

[Xianzhu, 2015-10-01 21:18:48]

A question: the painters are all stack allocated temporary objects and just hold
the reference during a method call like the following:
  FramePainter(frameView).paint();

Should this kind of reference also need Member<>?

[commit-bot: I haz the power, 2015-10-01 21:21:22]

Patchset 1 (id:??) landed as
https://crrev.com/1c2a93f3cdcf4673299a3c6c4b6b8b79c504f088
Cr-Commit-Position: refs/heads/master@{#351887}

[haraken, 2015-10-01 23:31:33]

LGTM

On 2015/10/01 21:18:48, Xianzhu wrote:
> A question: the painters are all stack allocated temporary objects and just
hold
> the reference during a method call like the following:
>   FramePainter(frameView).paint();
> 
> Should this kind of reference also need Member<>?

In terms of correctness, it is okay to use a raw pointer in STACK_ALLOCATED but
we explicitly use Member<> to indicate that we took care of the pointer. (So
you're right -- a raw pointer works fine in terms of correctness.)