[es7] implement exponentiation operator proposal

[es7] implement exponentiation operator proposal

Implements Stage 4 proposal from http://rwaldron.github.io/exponentiation-operator/,
without adding any knowledge of the feature to compiler backends.

BUG=v8:3915
LOG=Y
R=adamk@chromium.org, rossberg@chromium.org, littledan@chromium.org

Committed: https://crrev.com/17c92fe6bb62e11a43ef8c77d26410407a9828b5
Cr-Commit-Position: refs/heads/master@{#34890}

[caitp (gmail), 2016-02-08 21:30:38]

after about a year since the last try, here's another (simpler) go at the latest
version of the proposal.

There's some messy bits, to make the right-associativity of the `**` token work,
probably a better way to do that.

[caitp (gmail), 2016-02-08 22:09:44]

https://codereview.chromium.org/1678303002/diff/20001/test/webkit/fast/js/par...
File test/webkit/fast/js/parser-syntax-check-expected.txt (right):

https://codereview.chromium.org/1678303002/diff/20001/test/webkit/fast/js/par...
test/webkit/fast/js/parser-syntax-check-expected.txt:61: FAIL Valid:   "function
f() { ++ -- ++ a }" should NOT throw
The grammar change in the latest version of the proposal might be a bit
dangerous because of these ReferenceErrors becoming early errors /cc rwaldron
(but I assume people have been okay with this so far?)

[Rick Waldron, 2016-02-09 22:21:08]

On 2016/02/08 22:09:44, caitp wrote:
>
https://codereview.chromium.org/1678303002/diff/20001/test/webkit/fast/js/par...
> File test/webkit/fast/js/parser-syntax-check-expected.txt (right):
> 
>
https://codereview.chromium.org/1678303002/diff/20001/test/webkit/fast/js/par...
> test/webkit/fast/js/parser-syntax-check-expected.txt:61: FAIL Valid:  
"function
> f() { ++ -- ++ a }" should NOT throw

I don't know how to interpret this: 

FAIL Valid:   "++ -- ++ a" should NOT throw

But, that was never valid grammar.

> The grammar change in the latest version of the proposal might be a bit
> dangerous because of these ReferenceErrors becoming early errors /cc rwaldron
> (but I assume people have been okay with this so far?)

I'm concerned with this: 

> Implements Stage 4 proposal from
http://rwaldron.github.io/exponentiation-operator/,

Once I started writing the actual spec patch for http://github.com/tc39/ecma262,
I didn't back-port any changes that were made during review with Brian and
Andre. I know that the evaluation order is wrong here:
http://rwaldron.github.io/exponentiation-operator/, as a result of an attempt to
"over optimize" the spec language.

[caitp (gmail), 2016-02-09 23:09:09]

https://codereview.chromium.org/1678303002/diff/20001/test/webkit/fast/js/par...
File test/webkit/fast/js/parser-syntax-check-expected.txt (right):

https://codereview.chromium.org/1678303002/diff/20001/test/webkit/fast/js/par...
test/webkit/fast/js/parser-syntax-check-expected.txt:61: FAIL Valid:   "function
f() { ++ -- ++ a }" should NOT throw
On 2016/02/08 22:09:44, caitp wrote:
> The grammar change in the latest version of the proposal might be a bit
> dangerous because of these ReferenceErrors becoming early errors /cc rwaldron
> (but I assume people have been okay with this so far?)

In implementations today, it's a ReferenceError at runtime, rather than a
SyntaxError (although it might actually just be an early ReferenceError)

[caitp (gmail), 2016-02-09 23:12:48]

> I'm concerned with this: 
> 
> > Implements Stage 4 proposal from
> http://rwaldron.github.io/exponentiation-operator/,
> 
> Once I started writing the actual spec patch for
http://github.com/tc39/ecma262,
> I didn't back-port any changes that were made during review with Brian and
> Andre. I know that the evaluation order is wrong here:
> http://rwaldron.github.io/exponentiation-operator/, as a result of an attempt
to
> "over optimize" the spec language.

Hmm, could you link me to some of these discussions? I believe right now this is
mostly or entirely compatible with the implementation in gecko

[Rick Waldron, 2016-02-09 23:34:32]

On 2016/02/09 23:09:09, caitp wrote:
>
https://codereview.chromium.org/1678303002/diff/20001/test/webkit/fast/js/par...
> File test/webkit/fast/js/parser-syntax-check-expected.txt (right):
> 
>
https://codereview.chromium.org/1678303002/diff/20001/test/webkit/fast/js/par...
> test/webkit/fast/js/parser-syntax-check-expected.txt:61: FAIL Valid:  
"function
> f() { ++ -- ++ a }" should NOT throw
> On 2016/02/08 22:09:44, caitp wrote:
> > The grammar change in the latest version of the proposal might be a bit
> > dangerous because of these ReferenceErrors becoming early errors /cc
rwaldron
> > (but I assume people have been okay with this so far?)
> 
> In implementations today, it's a ReferenceError at runtime, rather than a
> SyntaxError (although it might actually just be an early ReferenceError)

In SpiderMonkey it's a SyntaxError (which is what I would expect).

[caitp (gmail), 2016-02-09 23:37:28]

On 2016/02/09 23:34:32, Rick Waldron wrote:
> On 2016/02/09 23:09:09, caitp wrote:
> >
>
https://codereview.chromium.org/1678303002/diff/20001/test/webkit/fast/js/par...
> > File test/webkit/fast/js/parser-syntax-check-expected.txt (right):
> > 
> >
>
https://codereview.chromium.org/1678303002/diff/20001/test/webkit/fast/js/par...
> > test/webkit/fast/js/parser-syntax-check-expected.txt:61: FAIL Valid:  
> "function
> > f() { ++ -- ++ a }" should NOT throw
> > On 2016/02/08 22:09:44, caitp wrote:
> > > The grammar change in the latest version of the proposal might be a bit
> > > dangerous because of these ReferenceErrors becoming early errors /cc
> rwaldron
> > > (but I assume people have been okay with this so far?)
> > 
> > In implementations today, it's a ReferenceError at runtime, rather than a
> > SyntaxError (although it might actually just be an early ReferenceError)
> 
> In SpiderMonkey it's a SyntaxError (which is what I would expect).

It's a WebKit test, which checks if eval() throws a SyntaxError or not

[Rick Waldron, 2016-02-09 23:53:36]

On 2016/02/09 23:12:48, caitp wrote:
> > I'm concerned with this: 
> > 
> > > Implements Stage 4 proposal from
> > http://rwaldron.github.io/exponentiation-operator/,
> > 
> > Once I started writing the actual spec patch for
> http://github.com/tc39/ecma262,
> > I didn't back-port any changes that were made during review with Brian and
> > Andre. I know that the evaluation order is wrong here:
> > http://rwaldron.github.io/exponentiation-operator/, as a result of an
attempt
> to
> > "over optimize" the spec language.
> 
> Hmm, could you link me to some of these discussions? I believe right now this
is
> mostly or entirely compatible with the implementation in gecko

Well, one discussion occurred over google hangout :P I've backported all of the
differences to the feature spec:
http://rwaldron.github.io/exponentiation-operator/

[Dan Ehrenberg, 2016-02-11 08:16:50]

https://codereview.chromium.org/1678303002/diff/1/src/contexts.h
File src/contexts.h (left):

https://codereview.chromium.org/1678303002/diff/1/src/contexts.h#oldcode98
src/contexts.h:98: 
Change needed?

https://codereview.chromium.org/1678303002/diff/1/src/parsing/token.h
File src/parsing/token.h (left):

https://codereview.chromium.org/1678303002/diff/1/src/parsing/token.h#oldcode174
src/parsing/token.h:174: 
Why a change here?

https://codereview.chromium.org/1678303002/diff/1/src/parsing/token.h
File src/parsing/token.h (right):

https://codereview.chromium.org/1678303002/diff/1/src/parsing/token.h#newcode218
src/parsing/token.h:218: return INIT <= tok && tok <= ASSIGN_EXP;
Maybe make constants expressing the start and end?

https://codereview.chromium.org/1678303002/diff/1/test/mjsunit/harmony/expone...
File test/mjsunit/harmony/exponentiation-operator.js (right):

https://codereview.chromium.org/1678303002/diff/1/test/mjsunit/harmony/expone...
test/mjsunit/harmony/exponentiation-operator.js:3: // found in the LICENSE file.
No test for the critical syntax error?

https://codereview.chromium.org/1678303002/diff/20001/src/parsing/parser-base.h
File src/parsing/parser-base.h (right):

https://codereview.chromium.org/1678303002/diff/20001/src/parsing/parser-base...
src/parsing/parser-base.h:2245: // somehow
Seems like a good thing to do before submitting this patch. Does this code
ensure that there's a SyntaxError in the -x**y case?

https://codereview.chromium.org/1678303002/diff/20001/test/webkit/fast/js/par...
File test/webkit/fast/js/parser-syntax-check-expected.txt (right):

https://codereview.chromium.org/1678303002/diff/20001/test/webkit/fast/js/par...
test/webkit/fast/js/parser-syntax-check-expected.txt:61: FAIL Valid:   "function
f() { ++ -- ++ a }" should NOT throw
On 2016/02/09 at 23:09:09, caitp wrote:
> On 2016/02/08 22:09:44, caitp wrote:
> > The grammar change in the latest version of the proposal might be a bit
> > dangerous because of these ReferenceErrors becoming early errors /cc
rwaldron
> > (but I assume people have been okay with this so far?)
> 
> In implementations today, it's a ReferenceError at runtime, rather than a
SyntaxError (although it might actually just be an early ReferenceError)

Yeah, good to call this out as dangerous. Let's do this change in another patch.
We have other things that the spec says should be SyntaxErrors, but we currently
make errors at runtime; maybe they should be changed, but it'd be good to
collect some more data before shipping. Shouldn't be too hard to add a
UseCounter (as I recently did for for-in-initializer), should it?

[caitp (gmail), 2016-02-11 12:57:24]

https://codereview.chromium.org/1678303002/diff/20001/src/parsing/parser-base.h
File src/parsing/parser-base.h (right):

https://codereview.chromium.org/1678303002/diff/20001/src/parsing/parser-base...
src/parsing/parser-base.h:2245: // somehow
On 2016/02/11 08:16:50, Dan Ehrenberg wrote:
> Seems like a good thing to do before submitting this patch. Does this code
> ensure that there's a SyntaxError in the -x**y case?

Yes it does-- the model for existing right associativity in v8 is just hard to
understand how to model this, since it's the only right associative binary op,
and doesn't fit well with the preexisting model. I'm not sure what the best
refactoring is yet, so i went with the simple hack first.

Could make it clearer by having a variable like `asspciativity` set to
`kRightAssociative` or something of the op is **, and change how the loop works
based on that. It's the same hack, just expressed more clearly?

I am sure people have preferences for this, but it is a very unusual behavior
for a binary op in js, so i wasn't sure how we wanted to do it, thus wanted
feedback on it

[caitp (gmail), 2016-02-11 15:32:34]

https://codereview.chromium.org/1678303002/diff/20001/src/parsing/parser-base.h
File src/parsing/parser-base.h (right):

https://codereview.chromium.org/1678303002/diff/20001/src/parsing/parser-base...
src/parsing/parser-base.h:2245: // somehow
On 2016/02/11 12:57:24, caitp wrote:
> On 2016/02/11 08:16:50, Dan Ehrenberg wrote:
> > Seems like a good thing to do before submitting this patch. Does this code
> > ensure that there's a SyntaxError in the -x**y case?
> 
> Yes it does-- the model for existing right associativity in v8 is just hard to
> understand how to model this, since it's the only right associative binary op,
> and doesn't fit well with the preexisting model. I'm not sure what the best
> refactoring is yet, so i went with the simple hack first.
> 
> Could make it clearer by having a variable like `asspciativity` set to
> `kRightAssociative` or something of the op is **, and change how the loop
works
> based on that. It's the same hack, just expressed more clearly?
> 
> I am sure people have preferences for this, but it is a very unusual behavior
> for a binary op in js, so i wasn't sure how we wanted to do it, thus wanted
> feedback on it

I've simplified the unary-op SyntaxError code and refactored this slightly, to
look a little bit cleaner --- but it's really the same hack and adds a few lines
of code

[caitp (gmail), 2016-02-11 23:46:55]

Patchset #6 (id:100001) has been deleted

[caitp (gmail), 2016-02-25 15:12:28]

(Verified this morning): This CL currently passes all of the new test262 tests
introduced in
https://github.com/tc39/test262/commit/304dbf0569457b0307b406984a8ab83cec99cf6d

[Dan Ehrenberg, 2016-02-25 19:17:41]

Glad to see it passes the tests; just a couple comments.

https://codereview.chromium.org/1678303002/diff/180001/src/parsing/parser.cc
File src/parsing/parser.cc (right):

https://codereview.chromium.org/1678303002/diff/180001/src/parsing/parser.cc#...
src/parsing/parser.cc:5641: if (op == Token::EXP) {
Callers already know whether they are doing EXP or ASSIGN_EXP. Seems like it
would be cleaner if this were two functions, since they don't share any code at
all.

https://codereview.chromium.org/1678303002/diff/180001/src/parsing/parser.cc#...
src/parsing/parser.cc:5687: return factory()->NewAssignment(Token::ASSIGN_MUL,
left, right, pos);
This should be unreachable because of the check preceding the
RewriteExponentiation call in ParseAssignmentExpression for invalid LHS errors.
How about write UNREACHABLE here?

[caitp (gmail), 2016-03-11 15:54:19]

addressed, sorry it took so long @_@

https://codereview.chromium.org/1678303002/diff/180001/src/parsing/parser.cc
File src/parsing/parser.cc (right):

https://codereview.chromium.org/1678303002/diff/180001/src/parsing/parser.cc#...
src/parsing/parser.cc:5641: if (op == Token::EXP) {
On 2016/02/25 19:17:41, Dan Ehrenberg wrote:
> Callers already know whether they are doing EXP or ASSIGN_EXP. Seems like it
> would be cleaner if this were two functions, since they don't share any code
at
> all.

Done.

https://codereview.chromium.org/1678303002/diff/180001/src/parsing/parser.cc#...
src/parsing/parser.cc:5687: return factory()->NewAssignment(Token::ASSIGN_MUL,
left, right, pos);
On 2016/02/25 19:17:41, Dan Ehrenberg wrote:
> This should be unreachable because of the check preceding the
> RewriteExponentiation call in ParseAssignmentExpression for invalid LHS
errors.
> How about write UNREACHABLE here?

Done.

[Dan Ehrenberg, 2016-03-14 20:45:51]

Description was changed from

==========
[es7] implement exponentiation operator proposal

Implements Stage 4 proposal from
http://rwaldron.github.io/exponentiation-operator/,
without adding any knowledge of the feature to compiler backends.

BUG=v8:3915
LOG=N
R=adamk@chromium.org, rossberg@chromium.org, littledan@chromium.org
==========

to

==========
[es7] implement exponentiation operator proposal

Implements Stage 4 proposal from
http://rwaldron.github.io/exponentiation-operator/,
without adding any knowledge of the feature to compiler backends.

BUG=v8:3915
LOG=Y
R=adamk@chromium.org, rossberg@chromium.org, littledan@chromium.org
==========

[Dan Ehrenberg, 2016-03-14 20:48:46]

Looks pretty good, just a couple more comments

https://codereview.chromium.org/1678303002/diff/260001/src/parsing/parser.cc
File src/parsing/parser.cc (right):

https://codereview.chromium.org/1678303002/diff/260001/src/parsing/parser.cc#...
src/parsing/parser.cc:5494: // backend support for exponent op, some day
I'm not so convinced that this is a bad way to go, long-term. Just curious, why
is the TODO assigned to bmeurer?

https://codereview.chromium.org/1678303002/diff/260001/test/cctest/test-parsi...
File test/cctest/test-parsing.cc (right):

https://codereview.chromium.org/1678303002/diff/260001/test/cctest/test-parsi...
test/cctest/test-parsing.cc:7383: "--+x ** 10",
Could you add parsing tests for **=, including in conjunction with an invalid
LHS (e.g., using destructuring)?

[caitp (gmail), 2016-03-14 21:05:14]

https://codereview.chromium.org/1678303002/diff/260001/src/parsing/parser.cc
File src/parsing/parser.cc (right):

https://codereview.chromium.org/1678303002/diff/260001/src/parsing/parser.cc#...
src/parsing/parser.cc:5494: // backend support for exponent op, some day
On 2016/03/14 20:48:46, Dan Ehrenberg wrote:
> I'm not so convinced that this is a bad way to go, long-term. Just curious,
why
> is the TODO assigned to bmeurer?

eh, it could be more `TODO(backend-knowledgable-people)`, I guess --- name is
just picked due to tech lead status

There are some advantages to implementing this in backends, such as not needing
to allocate a temp variable for the holder of the property, avoiding ToNumber()
in common cases, etc. It's not an urgent thing, though, and most applications
probably won't notice the difference.

https://codereview.chromium.org/1678303002/diff/260001/test/cctest/test-parsi...
File test/cctest/test-parsing.cc (right):

https://codereview.chromium.org/1678303002/diff/260001/test/cctest/test-parsi...
test/cctest/test-parsing.cc:7383: "--+x ** 10",
On 2016/03/14 20:48:46, Dan Ehrenberg wrote:
> Could you add parsing tests for **=, including in conjunction with an invalid
> LHS (e.g., using destructuring)?

Done.

[Dan Ehrenberg, 2016-03-14 21:13:25]

Sorry I didn't say before, but there are a few other places where you could
improve test coverage.

https://codereview.chromium.org/1678303002/diff/260001/src/parsing/parser.cc
File src/parsing/parser.cc (right):

https://codereview.chromium.org/1678303002/diff/260001/src/parsing/parser.cc#...
src/parsing/parser.cc:5494: // backend support for exponent op, some day
On 2016/03/14 at 21:05:14, caitp wrote:
> On 2016/03/14 20:48:46, Dan Ehrenberg wrote:
> > I'm not so convinced that this is a bad way to go, long-term. Just curious,
why
> > is the TODO assigned to bmeurer?
> 
> eh, it could be more `TODO(backend-knowledgable-people)`, I guess --- name is
just picked due to tech lead status
> 
> There are some advantages to implementing this in backends, such as not
needing to allocate a temp variable for the holder of the property, avoiding
ToNumber() in common cases, etc. It's not an urgent thing, though, and most
applications probably won't notice the difference.

If you want to insert a TODO, it should probably be assigned to yourself. See
https://google.github.io/styleguide/cppguide.html#TODO_Comments .

I'm not convinced that there'd be much benefit to putting it in the backends,
anyway--we're doing more things these days with desugaring, even though it
increases the number of temp variables, and we also have lots of calls to
ToNumber all over the place that we make do with performance-wise. I don't see
anything crazy about it. I'd rather we increase the separation of concerns
between the frontend and backends, rather than make the backends more
complicated, whenever possible.

https://codereview.chromium.org/1678303002/diff/280001/test/cctest/test-parsi...
File test/cctest/test-parsing.cc (right):

https://codereview.chromium.org/1678303002/diff/280001/test/cctest/test-parsi...
test/cctest/test-parsing.cc:7339: "x-- ** 10",
How about some successful parse tests here?

https://codereview.chromium.org/1678303002/diff/280001/test/mjsunit/harmony/e...
File test/mjsunit/harmony/exponentiation-operator.js (right):

https://codereview.chromium.org/1678303002/diff/280001/test/mjsunit/harmony/e...
test/mjsunit/harmony/exponentiation-operator.js:197: assertEquals(NaN, (-16) **
-0.5);
Tests for **= functioning correctly? How about verifying that overwriting
Math.pow doesn't have an effect on anything?

[caitp (gmail), 2016-03-14 22:52:12]

https://codereview.chromium.org/1678303002/diff/280001/test/cctest/test-parsi...
File test/cctest/test-parsing.cc (right):

https://codereview.chromium.org/1678303002/diff/280001/test/cctest/test-parsi...
test/cctest/test-parsing.cc:7339: "x-- ** 10",
On 2016/03/14 21:13:25, Dan Ehrenberg wrote:
> How about some successful parse tests here?

I'm not sure what you mean, this comment is put in the list of successful parse
tests

https://codereview.chromium.org/1678303002/diff/280001/test/mjsunit/harmony/e...
File test/mjsunit/harmony/exponentiation-operator.js (right):

https://codereview.chromium.org/1678303002/diff/280001/test/mjsunit/harmony/e...
test/mjsunit/harmony/exponentiation-operator.js:197: assertEquals(NaN, (-16) **
-0.5);
On 2016/03/14 21:13:25, Dan Ehrenberg wrote:
> Tests for **= functioning correctly? How about verifying that overwriting
> Math.pow doesn't have an effect on anything?

ah, I've added some tests to verify that overriding Math.pow doesn't affect the
algorithm, some operation ordering tests using Proxy, assertions about throwing
with bad LHS in assignment contexts (with a TODO to throw an early reference
error when LHS is a call expression, if we can ever really fix that). Most of
these aren't covered in test262, so maybe that's something Rick could add.

[Dan Ehrenberg, 2016-03-15 01:00:57]

https://codereview.chromium.org/1678303002/diff/300001/src/parsing/parser.cc
File src/parsing/parser.cc (right):

https://codereview.chromium.org/1678303002/diff/300001/src/parsing/parser.cc#...
src/parsing/parser.cc:5494: // avoid ToNumber() when possible (the common
cases).
Please remove this TODO.

[caitp (gmail), 2016-03-15 01:03:05]

https://codereview.chromium.org/1678303002/diff/300001/src/parsing/parser.cc
File src/parsing/parser.cc (right):

https://codereview.chromium.org/1678303002/diff/300001/src/parsing/parser.cc#...
src/parsing/parser.cc:5494: // avoid ToNumber() when possible (the common
cases).
On 2016/03/15 01:00:56, Dan Ehrenberg wrote:
> Please remove this TODO.

Done, but I think this is something that should be improved on later.

[Dan Ehrenberg, 2016-03-15 01:04:01]

lgtm

[caitp (gmail), 2016-03-15 01:06:49]

On 2016/03/15 01:04:01, Dan Ehrenberg wrote:
> lgtm

I'll give people a day or 2 to look it over and provide feedback before CQing

[caitp (gmail), 2016-03-18 13:29:28]

The CQ bit was checked by caitpotter88@gmail.com

[commit-bot: I haz the power, 2016-03-18 13:29:38]

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

[commit-bot: I haz the power, 2016-03-18 13:54:00]

Committed patchset #16 (id:320001)

[commit-bot: I haz the power, 2016-03-18 13:54:11]

Description was changed from

==========
[es7] implement exponentiation operator proposal

Implements Stage 4 proposal from
http://rwaldron.github.io/exponentiation-operator/,
without adding any knowledge of the feature to compiler backends.

BUG=v8:3915
LOG=Y
R=adamk@chromium.org, rossberg@chromium.org, littledan@chromium.org
==========

to

==========
[es7] implement exponentiation operator proposal

Implements Stage 4 proposal from
http://rwaldron.github.io/exponentiation-operator/,
without adding any knowledge of the feature to compiler backends.

BUG=v8:3915
LOG=Y
R=adamk@chromium.org, rossberg@chromium.org, littledan@chromium.org

Committed: https://crrev.com/17c92fe6bb62e11a43ef8c77d26410407a9828b5
Cr-Commit-Position: refs/heads/master@{#34890}
==========

[commit-bot: I haz the power, 2016-03-18 13:54:12]

Patchset 16 (id:??) landed as
https://crrev.com/17c92fe6bb62e11a43ef8c77d26410407a9828b5
Cr-Commit-Position: refs/heads/master@{#34890}

[nickie, 2016-03-21 08:51:48]

nikolaos@chromium.org changed reviewers:
+ nikolaos@chromium.org

[nickie, 2016-03-21 08:51:49]

https://codereview.chromium.org/1678303002/diff/320001/src/parsing/parser-base.h
File src/parsing/parser-base.h (right):

https://codereview.chromium.org/1678303002/diff/320001/src/parsing/parser-bas...
src/parsing/parser-base.h:141: #undef ALLOW_ACCESSORS
Shouldn't there be an #undef SCANNER_ACCESSORS here?

[caitp (gmail), 2016-03-21 10:44:17]

https://codereview.chromium.org/1678303002/diff/320001/src/parsing/parser-base.h
File src/parsing/parser-base.h (right):

https://codereview.chromium.org/1678303002/diff/320001/src/parsing/parser-bas...
src/parsing/parser-base.h:141: #undef ALLOW_ACCESSORS
Yes, there should! I'm surprised this doesn't trigger -Wmacro-redefined

[caitp (gmail), 2016-03-21 10:50:03]

https://codereview.chromium.org/1678303002/diff/320001/src/parsing/parser-base.h
File src/parsing/parser-base.h (right):

https://codereview.chromium.org/1678303002/diff/320001/src/parsing/parser-bas...
src/parsing/parser-base.h:141: #undef ALLOW_ACCESSORS
On 2016/03/21 10:44:17, caitp wrote:
> Yes, there should! I'm surprised this doesn't trigger -Wmacro-redefined

well, I guess I used a different name in scanner.h, so it's harmless enough ---
there's a CL up to fix it though