Classes: static should still be treated as a strict reserved word

Classes: static should still be treated as a strict reserved word

When --harmony-classes is enabled we did not treat static as a
strict reserved word.

BUG=v8:3642
LOG=Y
R=rossberg@chromium.org

Committed: https://code.google.com/p/v8/source/detail?r=25087

[arv (Not doing code reviews), 2014-10-20 16:56:50]

Patchset #1 (id:1) has been deleted

[arv (Not doing code reviews), 2014-10-20 17:00:07]

Patchset #1 (id:20001) has been deleted

[arv (Not doing code reviews), 2014-10-20 17:00:25]

arv@chromium.org changed reviewers:
+ rossberg@chromium.org

[arv (Not doing code reviews), 2014-10-20 17:02:44]

I'm confused. I can repro the error when running test262-es6 but it does not
reproduce anywhere else. I'll bang my head for a little longer

[arv (Not doing code reviews), 2014-10-20 17:10:05]

cleanup

[rossberg, 2014-10-20 17:16:21]

On 2014/10/20 17:02:44, arv wrote:
> I'm confused. I can repro the error when running test262-es6 but it does not
> reproduce anywhere else. I'll bang my head for a little longer

Hm, I could produce it quite easily by running d8 --harmony and just entering
the decl from the bug report.

[arv (Not doing code reviews), 2014-10-20 17:44:29]

On 2014/10/20 17:16:21, rossberg wrote:
> On 2014/10/20 17:02:44, arv wrote:
> > I'm confused. I can repro the error when running test262-es6 but it does not
> > reproduce anywhere else. I'll bang my head for a little longer
> 
> Hm, I could produce it quite easily by running d8 --harmony and just entering
> the decl from the bug report.

Me too. I'm say that this fixes the that case but the test262-es6 still fails.
The indivual tests in test262 passes. It is only when multiple tests are run it
fails.

  tools/run-tests.py --mode release --arch ia32 --download test262-es6/ch07

This makes me believe that we either have a bug in harmony_scoping or in
preparser vs parser.

[arv (Not doing code reviews), 2014-10-20 18:31:08]

On 2014/10/20 17:44:29, arv wrote:
> On 2014/10/20 17:16:21, rossberg wrote:
> > On 2014/10/20 17:02:44, arv wrote:
> > > I'm confused. I can repro the error when running test262-es6 but it does
not
> > > reproduce anywhere else. I'll bang my head for a little longer
> > 
> > Hm, I could produce it quite easily by running d8 --harmony and just
entering
> > the decl from the bug report.
> 
> Me too. I'm say that this fixes the that case but the test262-es6 still fails.
> The indivual tests in test262 passes. It is only when multiple tests are run
it
> fails.
> 
>   tools/run-tests.py --mode release --arch ia32 --download test262-es6/ch07
> 
> This makes me believe that we either have a bug in harmony_scoping or in
> preparser vs parser.

More info. If I change the testcfg.py to --harmony-scoping I still get the
error.

[rossberg, 2014-10-31 10:16:04]

https://codereview.chromium.org/652743009/diff/60001/src/parser.h
File src/parser.h (right):

https://codereview.chromium.org/652743009/diff/60001/src/parser.h#newcode856
src/parser.h:856: return identifier->IsOneByteEqualTo("let") ||
Is there a reason we cannot fold these into the scanner's
IdentifierIsFutureStrictReserved?

https://codereview.chromium.org/652743009/diff/60001/test/cctest/test-parsing.cc
File test/cctest/test-parsing.cc (right):

https://codereview.chromium.org/652743009/diff/60001/test/cctest/test-parsing...
test/cctest/test-parsing.cc:1831: "function " #NAME "() { }",                  
\
Maybe add a function expression as well.

https://codereview.chromium.org/652743009/diff/60001/test/cctest/test-parsing...
test/cctest/test-parsing.cc:1834: #NAME " = 1;",                               
\
Perhaps also add a "+=" case.

[arv (Not doing code reviews), 2014-10-31 10:44:07]

Move handling of identifiers into IdentifierIsFutureStrictReserved

[arv (Not doing code reviews), 2014-10-31 10:44:18]

PTAL

https://codereview.chromium.org/652743009/diff/60001/src/parser.h
File src/parser.h (right):

https://codereview.chromium.org/652743009/diff/60001/src/parser.h#newcode856
src/parser.h:856: return identifier->IsOneByteEqualTo("let") ||
On 2014/10/31 10:16:04, rossberg wrote:
> Is there a reason we cannot fold these into the scanner's
> IdentifierIsFutureStrictReserved?

Done.

https://codereview.chromium.org/652743009/diff/60001/test/cctest/test-parsing.cc
File test/cctest/test-parsing.cc (right):

https://codereview.chromium.org/652743009/diff/60001/test/cctest/test-parsing...
test/cctest/test-parsing.cc:1831: "function " #NAME "() { }",                  
\
On 2014/10/31 10:16:04, rossberg wrote:
> Maybe add a function expression as well.

Done.

https://codereview.chromium.org/652743009/diff/60001/test/cctest/test-parsing...
test/cctest/test-parsing.cc:1834: #NAME " = 1;",                               
\
On 2014/10/31 10:16:04, rossberg wrote:
> Perhaps also add a "+=" case.

Done.

[rossberg, 2014-10-31 11:35:33]

lgtm

[arv (Not doing code reviews), 2014-10-31 11:41:53]

On 2014/10/31 11:35:33, rossberg wrote:
> lgtm

This is hitting an assert. Looking into it.

[arv (Not doing code reviews), 2014-10-31 12:10:05]

Use let and not eval. Add tests that covers this too

[arv (Not doing code reviews), 2014-10-31 12:11:54]

Found the bug and added tests that covers this.

https://codereview.chromium.org/652743009/diff/100001/src/preparser.h
File src/preparser.h (right):

https://codereview.chromium.org/652743009/diff/100001/src/preparser.h#newcode634
src/preparser.h:634: type_ == kLetIdentifier || type_ == kStaticIdentifier ||
This is where the bug was. I had kEvalIdentifier instead of kLetIdentifier.

[rossberg, 2014-10-31 12:27:17]

lgtm

[arv (Not doing code reviews), 2014-11-03 19:53:47]

Committed patchset #4 (id:100001) manually as 25087 (presubmit successful).