Make let/const outside of the extended mode early errors (under harmony flag).

Make let/const outside of the extended mode early errors (under harmony flag).

The ES.next drafts require that source code that matches the productions for
let and const bindings outside the extended mode trigger early syntax
errors. This CL adapts the parser / preparser accordingly under the harmony
scoping flag.

Summary:
* Harmony scoping flag not set: Old semantics allowing const in classic mode
with function level scope. Const binding in strict mode and let bindings in
classic and strict mode trigger early syntax errors.
* Harmony scoping is set: Use new harmony const and let in
extended mode and old const in classic mode. This is to preserve
compatibility with current web pages that already use
non-standard implementations of const. An early syntax error is
thrown on const in strict mode and on let in classic and strict
mode.

This depends on:
http://codereview.chromium.org/8562002/

TEST=mjsunit/harmony/block-early-errors.js

Committed: http://code.google.com/p/v8/source/detail?r=10079

[Steven, 2011-11-14 08:49:05]

PTAL.

[Jakob Kummerow, 2011-11-14 10:43:47]

LGTM

[Erik Corry, 2011-11-14 20:25:03]

Does this make 'const' into a syntax error in classic mode?  That would seem to
be a big compatibility problem.

[Steven, 2011-11-14 22:14:50]

I've updated the description with more thorough information. The CL preserves
the old semantics for const if the harmony scoping flag is not set, so at the
moment it does not break compatibility.
However, the implementation follows the current draft specification when the
harmony scoping flag is set (with an exception: see the CL description), i.e.
throwing early syntax errors for const and let declarations in classic and
strict mode. So yes, this will break compatibility once those changes become
active/visible.

[Erik Corry, 2011-11-15 08:05:20]

This confuses user-level opt-in and developer-level opt in.  As I understand it,
the --harmony flag is supposed to be simulating a browser in the future where a
Harmony-based ES.next standard has been ratified.  At that point there will
still be three modes (classic, strict, extended) and classic mode will still
need to handle all the pages where the developer has not opted into strict or
harmony semantics.  Those pages contain 'const' and we won't want to break them
when that day comes.

Therefore, of the two modes with --harmony we only need the one that is
currently reserved for the natives.

[Steven, 2011-11-15 09:54:26]

@Erik: Yes I can see that you would want to preserve compatibility. I have
changed the CL accordingly, i.e. to use the variant which was only used for
natives before. However, note that the harmony spec in this regard does not only
add new things in the extended mode, but also explicitly disallows things in
classic and strict mode. One could argue, that the spec shouldn't do that in the
first place.

@Jakob: Can you take a quick look again? I've also updated the preparser now. I
will introduce tests that make sure that the parser and preparser are in sync in
a subsequent CL.

[Jakob Kummerow, 2011-11-15 12:59:23]

LGTM with a nit.

http://codereview.chromium.org/8564001/diff/2002/test/mjsunit/harmony/block-e...
File test/mjsunit/harmony/block-early-errors.js (right):

http://codereview.chromium.org/8564001/diff/2002/test/mjsunit/harmony/block-e...
test/mjsunit/harmony/block-early-errors.js:34: string.indexOf("Illegal const")
>= 0);
This line is no longer necessary.