Add initial support for [Exposed=xx] extended IDL attribute

Add initial support for [Exposed=xx] extended IDL attribute

Add initial support for [Exposed=xx] extended IDL attribute:
http://heycam.github.io/webidl/#Exposed

This is adapted from our existing Blink-specific [GlobalContext=xx] IDL
extended attribute as the functionality is identical (select on which
global interface the interface is exposed).

There are 2 remaining issues that I am planning to address later on:
- The mapping between global identifiers and global IDL interfaces is currently
  manual but is supposed to rely on [Global] / [PrimaryGlobal] attributes
  instead, which we do not support yet.
- The values are still separated by '&' instead of ',' as per Web IDL
  specification. Having comma-separated values here confuses the parser as
  extended IDL attributes are already comma-separated. I was not able to add
  support for this in the Blink IDL lexer yet.
(Nils: using commas to separate makes parsing *very* hard,
and I don't think it's worth supporting.)

There is no web-exposed behavior change. This change just makes our Blink IDL
more standard.

R=haraken@chromium.org, nbarth@chromium.org
BUG=369115
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=173168

[Inactive, 2014-05-02 00:55:10]

Any help to get the comma-separated values to work in Extended Attribute values
would be appreciated. I am not quite sure how the parser to make the distinction
between the next comma-separated value and the next extended attribute, besides
the lack of space / linebreak after the comma. The thing is that our lexer
ignores spaces anyway.

[haraken, 2014-05-02 01:23:29]

LGTM

[Nils Barth (inactive), 2014-05-02 02:43:55]

On 2014/05/02 00:55:10, Chris Dumez wrote:
> Any help to get the comma-separated values to work in Extended Attribute
values
> would be appreciated. I am not quite sure how the parser to make the
distinction
> between the next comma-separated value and the next extended attribute,
besides
> the lack of space / linebreak after the comma. The thing is that our lexer
> ignores spaces anyway.

This made my eyes cross too: let's keep using | as a separator.

The problem is that the Web IDL grammar for extended attributes is
context-*sensitive*.

Consider parsing [Exposed=Window,Worker,Global], which should be parsed as
[Exposed=Window,Worker] + [Global].
This can't be done without semantic analysis: you need to know that |Global| is
not a valid
value for [Exposed].

There's an upstream bug about this, that I've commented on in detail.
"Exposed=Window,Worker" will be parsed to 2 extended attributes
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24959

These comma-separated identifier lists are only used as values for 3 extended
attributes,
and using | as a separator handles this fine.
(Probably better would be ; which has been proposed upstream; if that's used, we
can switch.)

[Nils Barth (inactive), 2014-05-02 02:49:48]

LGTM, thanks!

https://codereview.chromium.org/265773010/diff/1/Source/bindings/scripts/gene...
File Source/bindings/scripts/generate_global_constructors.py (right):

https://codereview.chromium.org/265773010/diff/1/Source/bindings/scripts/gene...
Source/bindings/scripts/generate_global_constructors.py:53: # FIXME: We should
add support for [Global=xx] extended attribute instead of hard-coding this
mapping.
Could you wrap the comment?
(No need to open a bug for [Global] if going to fix immediately.)

https://codereview.chromium.org/265773010/diff/1/Source/bindings/scripts/gene...
Source/bindings/scripts/generate_global_constructors.py:75: # FIXME: Web IDL
says the global names are comma-separated.
Could you note which that is a problem, and link to the upstream bug?
# FIXME: In spec names are comma-separated, but that makes parsing very
difficult:
# https://www.w3.org/Bugs/Public/show_bug.cgi?id=24959

[Inactive, 2014-05-02 03:04:06]

On 2014/05/02 02:43:55, Nils Barth wrote:
> On 2014/05/02 00:55:10, Chris Dumez wrote:
> > Any help to get the comma-separated values to work in Extended Attribute
> values
> > would be appreciated. I am not quite sure how the parser to make the
> distinction
> > between the next comma-separated value and the next extended attribute,
> besides
> > the lack of space / linebreak after the comma. The thing is that our lexer
> > ignores spaces anyway.
> 
> This made my eyes cross too: let's keep using | as a separator.
> 
> The problem is that the Web IDL grammar for extended attributes is
> context-*sensitive*.
> 
> Consider parsing [Exposed=Window,Worker,Global], which should be parsed as
> [Exposed=Window,Worker] + [Global].
> This can't be done without semantic analysis: you need to know that |Global|
is
> not a valid
> value for [Exposed].
> 
> There's an upstream bug about this, that I've commented on in detail.
> "Exposed=Window,Worker" will be parsed to 2 extended attributes
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24959
> 
> These comma-separated identifier lists are only used as values for 3 extended
> attributes,
> and using | as a separator handles this fine.
> (Probably better would be ; which has been proposed upstream; if that's used,
we
> can switch.)

Do you mind if I keep using '&' as separator or do you want me to switch to
using '|'?
The reason I used '&' as separator for [GlobalContext] and now [Exposed] is that
I found it a little bit clearer as what we really mean is "AND", not "OR".

[Inactive, 2014-05-02 03:08:36]

https://codereview.chromium.org/265773010/diff/1/Source/bindings/scripts/gene...
File Source/bindings/scripts/generate_global_constructors.py (right):

https://codereview.chromium.org/265773010/diff/1/Source/bindings/scripts/gene...
Source/bindings/scripts/generate_global_constructors.py:53: # FIXME: We should
add support for [Global=xx] extended attribute instead of hard-coding this
mapping.
On 2014/05/02 02:49:48, Nils Barth wrote:
> Could you wrap the comment?
> (No need to open a bug for [Global] if going to fix immediately.)

Done.

https://codereview.chromium.org/265773010/diff/1/Source/bindings/scripts/gene...
Source/bindings/scripts/generate_global_constructors.py:75: # FIXME: Web IDL
says the global names are comma-separated.
On 2014/05/02 02:49:48, Nils Barth wrote:
> Could you note which that is a problem, and link to the upstream bug?
> # FIXME: In spec names are comma-separated, but that makes parsing very
> difficult:
> # https://www.w3.org/Bugs/Public/show_bug.cgi?id=24959

Done.

[Nils Barth (inactive), 2014-05-02 03:08:38]

On 2014/05/02 03:04:06, Chris Dumez wrote:
> Do you mind if I keep using '&' as separator or do you want me to switch to
> using '|'?
> The reason I used '&' as separator for [GlobalContext] and now [Exposed] is
that
> I found it a little bit clearer as what we really mean is "AND", not "OR".

& is fine here, and clearer, as you say!
(Sorry for being unclear!)

[Inactive, 2014-05-02 03:11:29]

The CQ bit was checked by ch.dumez@samsung.com

[commit-bot: I haz the power, 2014-05-02 03:11:53]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ch.dumez@samsung.com/265773010/20001

[commit-bot: I haz the power, 2014-05-02 04:11:50]

Change committed as 173168