IDL build: Split global objects computation from global constructors computation

IDL build: Split global objects computation from global constructors computation

Preliminary CL for splitting global constructor computation between core
and modules.
Straightforward, but needed for pipeline.

Computation of global constructors (as partial interface definitions) depends
on global *objects* (interface definitions with [Global] or [PartialGlobal]).

We want to split global *constructors* between core and modules (as separate
partial interface .idl files), but we first need to compute global *objects*.
Thus we split this computation into 2 steps.

Also a bit of cleanup.

Followup CLs:
* Split global constructors computation between core and modules
* Split global objects computation between core and modules
...at which point the bindings build will be 100% split!

R=haraken
BUG=358074
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=175267

[Nils Barth (inactive), 2014-06-02 06:04:08]

Last vertical split!
(Splits global constructor computation in 2.)
After this just split each step into core vs. modules,
and then build is split!

[haraken, 2014-06-02 07:41:30]

https://codereview.chromium.org/309793002/diff/60001/Source/bindings/scripts/...
File Source/bindings/scripts/compute_global_objects.py (right):

https://codereview.chromium.org/309793002/diff/60001/Source/bindings/scripts/...
Source/bindings/scripts/compute_global_objects.py:63: raise ValueError('The
[Global] and [PrimaryGlobal] extended attributes '

Is it worth supporting extended attribute values for [PrimaryGlobal]? I guess
it's just used in Window as [PrimaryGlobal] (with no extended attribute values).

https://codereview.chromium.org/309793002/diff/60001/Source/bindings/scripts/...
Source/bindings/scripts/compute_global_objects.py:65: global_key =
next(iter(global_keys))

Nit: Can we write:

global_key = global_keys[0]

?

[Nils Barth (inactive), 2014-06-02 07:55:12]

https://codereview.chromium.org/309793002/diff/60001/Source/bindings/scripts/...
File Source/bindings/scripts/compute_global_objects.py (right):

https://codereview.chromium.org/309793002/diff/60001/Source/bindings/scripts/...
Source/bindings/scripts/compute_global_objects.py:63: raise ValueError('The
[Global] and [PrimaryGlobal] extended attributes '
On 2014/06/02 07:41:30, haraken wrote:
> Is it worth supporting extended attribute values for [PrimaryGlobal]? I guess
> it's just used in Window as [PrimaryGlobal] (with no extended attribute
values).

It's defined as such in the spec:
"""The [Global] and [PrimaryGlobal] extended attributes must either take no
arguments or take an identifier list."""
http://heycam.github.io/webidl/#Global

I think this is just for simplicity: it means we can treat them both the same,
even though we don't expect that [PrimaryGlobal] will be used for anything
except Window.
(It's a bit general, admittedly.)

https://codereview.chromium.org/309793002/diff/60001/Source/bindings/scripts/...
Source/bindings/scripts/compute_global_objects.py:65: global_key =
next(iter(global_keys))
On 2014/06/02 07:41:30, haraken wrote:
> 
> Nit: Can we write:
> 
> global_key = global_keys[0]
> 
> ?

No, b/c it's a (frozen) set.
We could do list(global_keys)[0], but next(iter(...)) is a bit more Pythonic.

There was a long discussion a few years ago about syntax sugar for this, and it
was rejected:
http://bugs.python.org/issue7212

[haraken, 2014-06-02 07:57:16]

On 2014/06/02 07:55:12, Nils Barth wrote:
>
https://codereview.chromium.org/309793002/diff/60001/Source/bindings/scripts/...
> File Source/bindings/scripts/compute_global_objects.py (right):
> 
>
https://codereview.chromium.org/309793002/diff/60001/Source/bindings/scripts/...
> Source/bindings/scripts/compute_global_objects.py:63: raise ValueError('The
> [Global] and [PrimaryGlobal] extended attributes '
> On 2014/06/02 07:41:30, haraken wrote:
> > Is it worth supporting extended attribute values for [PrimaryGlobal]? I
guess
> > it's just used in Window as [PrimaryGlobal] (with no extended attribute
> values).
> 
> It's defined as such in the spec:
> """The [Global] and [PrimaryGlobal] extended attributes must either take no
> arguments or take an identifier list."""
> http://heycam.github.io/webidl/#Global
> 
> I think this is just for simplicity: it means we can treat them both the same,
> even though we don't expect that [PrimaryGlobal] will be used for anything
> except Window.
> (It's a bit general, admittedly.)
> 
>
https://codereview.chromium.org/309793002/diff/60001/Source/bindings/scripts/...
> Source/bindings/scripts/compute_global_objects.py:65: global_key =
> next(iter(global_keys))
> On 2014/06/02 07:41:30, haraken wrote:
> > 
> > Nit: Can we write:
> > 
> > global_key = global_keys[0]
> > 
> > ?
> 
> No, b/c it's a (frozen) set.
> We could do list(global_keys)[0], but next(iter(...)) is a bit more Pythonic.
> 
> There was a long discussion a few years ago about syntax sugar for this, and
it
> was rejected:
> http://bugs.python.org/issue7212

oh, thanks for the detais! LGTM.

[Nils Barth (inactive), 2014-06-02 08:13:07]

On 2014/06/02 07:57:16, haraken wrote:
> oh, thanks for the detais! LGTM.

n/p!
Properly we should remove the hard-coding of Window and look for [PrimaryGlobal]
instead,
but that seems far too picky (lotta code for no difference), and Window is
hard-coded anyway.

[Nils Barth (inactive), 2014-06-02 08:22:46]

The CQ bit was checked by nbarth@chromium.org

[commit-bot: I haz the power, 2014-06-02 08:23:14]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/nbarth@chromium.org/309793002/60001

[commit-bot: I haz the power, 2014-06-02 09:41:02]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  blink_presubmit on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/blink_presubmit/builds/6652)

[commit-bot: I haz the power, 2014-06-02 09:53:39]

Change committed as 175267