Oilpan: move Location to the oilpan heap.

Oilpan: move Location to the oilpan heap.

Also add missing transition type handling for [PutForwards] over
garbage collected interface types.

R=haraken@chromium.org
BUG=340522
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=169538

[sof, 2014-03-19 08:31:34]

Please take a look.

[haraken, 2014-03-19 08:34:32]

LGTM

[sof, 2014-03-19 08:46:29]

The CQ bit was checked by sigbjornf@opera.com

[commit-bot: I haz the power, 2014-03-19 08:46:36]

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

[commit-bot: I haz the power, 2014-03-19 09:49:39]

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

[commit-bot: I haz the power, 2014-03-19 09:49:39]

Try jobs failed on following builders:
  tryserver.blink on linux_blink_dbg

[sof, 2014-03-19 09:50:41]

The CQ bit was checked by sigbjornf@opera.com

[commit-bot: I haz the power, 2014-03-19 09:50:49]

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

[commit-bot: I haz the power, 2014-03-19 09:54:27]

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

[commit-bot: I haz the power, 2014-03-19 09:54:27]

Try jobs failed on following builders:
  tryserver.blink on linux_blink_dbg

[sof, 2014-03-19 09:55:24]

The CQ bit was checked by sigbjornf@opera.com

[commit-bot: I haz the power, 2014-03-19 09:55:46]

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

[commit-bot: I haz the power, 2014-03-19 10:57:18]

Change committed as 169538

[Nils Barth (inactive), 2014-03-20 03:55:42]

(Delayed LGTM from POV of IDL compiler; thanks!)

[sof, 2014-03-20 07:35:10]

On 2014/03/20 03:55:42, Nils Barth wrote:
> (Delayed LGTM from POV of IDL compiler; thanks!)

Background&minor question on preferred structure for any later IDL compiler
changes - is the preference to put somewhat ad-hoc bindings on the values we're
instantiating templates over (e.g., 'attribute.ref_ptr' in this CL) over
deriving them locally in the template -- {% set locally_useful = value1 if
condition else value2 %} ?

[Nils Barth (inactive), 2014-03-20 07:56:50]

On 2014/03/20 07:35:10, sof wrote:
> Background&minor question on preferred structure for any later IDL compiler
> changes - is the preference to put somewhat ad-hoc bindings on the values
we're
> instantiating templates over (e.g., 'attribute.ref_ptr' in this CL) over
> deriving them locally in the template -- {% set locally_useful = value1 if
> condition else value2 %} ?

That's a good question; I've added a note in the docs about it:
http://www.chromium.org/developers/design-documents/idl-compiler#TOC-Back-end...

Simply, {% set %} is fine if it's only locally useful, only used once, and
easily derived
from existing information.

In this case it's complex information (need to introspect the IDL type of the
attribute),
so doing it in Python is best.
You're depending on attribute.idl_type.is_will_be_garbage_collected, and that
would require
passing the IDL type object (attribute.idl_type) into the template context!

|pass_ref_ptr| in the interface context is a good example:
at first I used a {% set %} statement because it was only used in one place and
could be determined
from the existing |is_will_be_garbage_collected| (boolean) variable,
but then it was used in multiple places and so I put it into the interface
context.

In this case you have a single use, so it would normally be better to use {% set
%},
but it's complex data, so putting it in the attribute context dictionary display
as you did is correct.

(Though the explanation is long, I assume in practice it's easy to judge.)

Thanks for checking and your attention to detail!

[sof, 2014-03-20 08:20:11]

On 2014/03/20 07:56:50, Nils Barth wrote:
> On 2014/03/20 07:35:10, sof wrote:
> > Background&minor question on preferred structure for any later IDL compiler
> > changes - is the preference to put somewhat ad-hoc bindings on the values
> we're
> > instantiating templates over (e.g., 'attribute.ref_ptr' in this CL) over
> > deriving them locally in the template -- {% set locally_useful = value1 if
> > condition else value2 %} ?
> 
> That's a good question; I've added a note in the docs about it:
>
http://www.chromium.org/developers/design-documents/idl-compiler#TOC-Back-end...
> 
...useful explanation elided...
>

Great, thanks for writing that out; will try to follow that. I do think it will
pay off to have guidance written down on what to prefer and not.

And if they lessen the need for learning the nuances of another templating DSL,
bonus.