Add a flag for legacy const semantics

Add a flag for legacy const semantics

This flag is on by default but it will allow us to turn that off in
favor of harmony-sloppy in the future.

BUG=v8:3305, v8:2198
LOG=N
R=littledan@chromium.org, rossberg@chromium.org

Committed: https://crrev.com/3973642c98501b3fc5a38c7cde6a908c15222edc
Cr-Commit-Position: refs/heads/master@{#29526}

[arv (Not doing code reviews), 2015-07-06 21:08:36]

WDYT?

The idea is to make harmony-sloppy cover let and const but that legacy-const has
higher priority so that if both are true we will continue to use legacy const.

[Dan Ehrenberg, 2015-07-06 21:26:12]

I like this change; my only concern is our behavior in sloppy mode when the flag
is turned off when we see const. What were const's semantics before legacy const
was introduced? Was it treated like a variable name, like let? It looks like
that's what this code does. But it looks to me like we should throw a "not
implemented" error. We won't ship this flag as off until sloppy const is
implemented, so that error should be unreachable (right?). I don't want people
on the web to accidentally start using const as a variable name.

https://codereview.chromium.org/1218803006/diff/1/src/parser.cc
File src/parser.cc (right):

https://codereview.chromium.org/1218803006/diff/1/src/parser.cc#newcode1385
src/parser.cc:1385: }
Do we want to interpret const as a variable (like let) if it is not allowed? I
think it should be an error if we encounter const but we don't have a reading to
interpret it (legacy or ES6).

https://codereview.chromium.org/1218803006/diff/1/src/parser.cc#newcode2435
src/parser.cc:2435: } else if (peek() == Token::CONST && allow_const()) {
How do we interpret the const token if const is not allowed?

https://codereview.chromium.org/1218803006/diff/1/src/preparser.cc
File src/preparser.cc (right):

https://codereview.chromium.org/1218803006/diff/1/src/preparser.cc#newcode197
src/preparser.cc:197: }
Error if allow_const is false?

[arv (Not doing code reviews), 2015-07-06 21:32:16]

If this flag is false we should report something like "unexpected token const".
Let me add a message test.

[arv (Not doing code reviews), 2015-07-06 21:35:25]

https://codereview.chromium.org/1218803006/diff/1/src/parser.cc
File src/parser.cc (right):

https://codereview.chromium.org/1218803006/diff/1/src/parser.cc#newcode1385
src/parser.cc:1385: }
On 2015/07/06 21:26:12, Dan Ehrenberg wrote:
> Do we want to interpret const as a variable (like let) if it is not allowed? I
> think it should be an error if we encounter const but we don't have a reading
to
> interpret it (legacy or ES6).

It should do that already since CONST is a keyword.

https://codereview.chromium.org/1218803006/diff/1/src/parser.cc#newcode2435
src/parser.cc:2435: } else if (peek() == Token::CONST && allow_const()) {
On 2015/07/06 21:26:12, Dan Ehrenberg wrote:
> How do we interpret the const token if const is not allowed?

The code is unreachable. The callers peek already.

https://codereview.chromium.org/1218803006/diff/1/src/preparser.cc
File src/preparser.cc (right):

https://codereview.chromium.org/1218803006/diff/1/src/preparser.cc#newcode197
src/preparser.cc:197: }
On 2015/07/06 21:26:12, Dan Ehrenberg wrote:
> Error if allow_const is false?

ParseStatement will error.

[arv (Not doing code reviews), 2015-07-06 21:41:51]

Add message tests

[Dan Ehrenberg, 2015-07-06 22:06:40]

lgtm

[arv (Not doing code reviews), 2015-07-07 15:13:50]

The CQ bit was checked by arv@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-07-07 15:14:03]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1218803006/20001

[commit-bot: I haz the power, 2015-07-07 15:50:20]

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

[commit-bot: I haz the power, 2015-07-07 15:50:21]

Dry run: This issue passed the CQ dry run.

[adamk, 2015-07-07 20:55:46]

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

[adamk, 2015-07-07 20:55:47]

I have a similar concern to Dan's, I think: are we ever going to turn off legacy
const without turning on ES6 sloppy const? If not, then this flag seems
redundant with --harmony-sloppy.

[arv (Not doing code reviews), 2015-07-07 21:22:17]

On 2015/07/07 20:55:47, adamk wrote:
> I have a similar concern to Dan's, I think: are we ever going to turn off
legacy
> const without turning on ES6 sloppy const? If not, then this flag seems
> redundant with --harmony-sloppy.

We talked offline. The goal is to allow us to ship let/class/function in sloppy
mode independent of legacy const.

[adamk, 2015-07-07 21:55:13]

The CQ bit was checked by adamk@chromium.org

[adamk, 2015-07-07 21:55:13]

lgtm

[commit-bot: I haz the power, 2015-07-07 21:55:39]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1218803006/20001

[commit-bot: I haz the power, 2015-07-07 21:57:15]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-07-07 21:57:28]

Patchset 2 (id:??) landed as
https://crrev.com/3973642c98501b3fc5a38c7cde6a908c15222edc
Cr-Commit-Position: refs/heads/master@{#29526}