Block scoped const variables.

Block scoped const variables.

This implements block scoped 'const' declared variables in harmony mode. They
have a temporal dead zone semantics similar to 'let' bindings, i.e. accessing
uninitialized 'const' bindings in throws a ReferenceError.

As for 'let' bindings, the semantics of 'const' bindings in global scope is not
correctly implemented yet. Furthermore assignments to 'const's are silently
ignored. Another CL will introduce treatment of those assignments as early
errors.

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

[Steven, 2011-09-22 15:00:08]

PTAL.

[Steven, 2011-10-17 13:05:26]

Rebased this to tip of tree. Could you please take a look.

[fschneider, 2011-10-21 09:19:40]

Almost there. You probably do need to add a bailout in the hydrogen-compiler,
don't you?

http://codereview.chromium.org/7992005/diff/18001/src/parser.cc
File src/parser.cc (right):

http://codereview.chromium.org/7992005/diff/18001/src/parser.cc#newcode1694
src/parser.cc:1694: if (top_scope_->num_var_or_const() > kMaxNumFunctionLocals)
{
This function contains a lot of duplicated code. Can you arrange it so to avoid
duplication where possible?

[Steven, 2011-10-24 09:37:55]

Added a bailout to hydrogen. Sorry also rebased in between somewhere. Please
take another look.

http://codereview.chromium.org/7992005/diff/18001/src/parser.cc
File src/parser.cc (right):

http://codereview.chromium.org/7992005/diff/18001/src/parser.cc#newcode1694
src/parser.cc:1694: if (top_scope_->num_var_or_const() > kMaxNumFunctionLocals)
{
Done. Was actually easier than I thought to add it to ParseVariableDeclarations.

On 2011/10/21 09:19:40, fschneider wrote:
> This function contains a lot of duplicated code. Can you arrange it so to
avoid
> duplication where possible?

[fschneider, 2011-10-24 12:58:13]

LGTM with a few minor comments.

http://codereview.chromium.org/7992005/diff/23028/src/contexts.cc
File src/contexts.cc (right):

http://codereview.chromium.org/7992005/diff/23028/src/contexts.cc#newcode204
src/contexts.cc:204: *binding_flags = mode == CONST
Maybe add parenthesis around mode == CONST for better readability.

http://codereview.chromium.org/7992005/diff/23028/src/ia32/full-codegen-ia32.cc
File src/ia32/full-codegen-ia32.cc (right):

http://codereview.chromium.org/7992005/diff/23028/src/ia32/full-codegen-ia32....
src/ia32/full-codegen-ia32.cc:714: bool binding_needs_init =
EmitDeclaration is used in two places. Is it possible to use
variable->binding_needs_init() instead here?

http://codereview.chromium.org/7992005/diff/23028/src/runtime.cc
File src/runtime.cc (right):

http://codereview.chromium.org/7992005/diff/23028/src/runtime.cc#newcode8880
src/runtime.cc:8880: UNREACHABLE();
Not sure, but you may have to return something here to make the compiler happy.

[Steven, 2011-10-24 14:05:18]

Sorry I forgot to remove redundant code from the preparser. Can you please take
a quick look at the diff between the patchsets?

I also adapted the mode of named function expressions to be CONST_HARMONY. I
cannot write a test case for this because the difference between CONST and
CONST_HARMONY for function variables is not observable yet.

http://codereview.chromium.org/7992005/diff/23028/src/contexts.cc
File src/contexts.cc (right):

http://codereview.chromium.org/7992005/diff/23028/src/contexts.cc#newcode204
src/contexts.cc:204: *binding_flags = mode == CONST
On 2011/10/24 12:58:13, fschneider wrote:
> Maybe add parenthesis around mode == CONST for better readability.

Done.

http://codereview.chromium.org/7992005/diff/23028/src/ia32/full-codegen-ia32.cc
File src/ia32/full-codegen-ia32.cc (right):

http://codereview.chromium.org/7992005/diff/23028/src/ia32/full-codegen-ia32....
src/ia32/full-codegen-ia32.cc:714: bool binding_needs_init =
Unfortunately for DYNAMIC_GLOBAL variables we can only get the mode used in the
declaration from the declaration object and not from the variable itself. It
does for example occur with eval('var foo;') in global scope. We can't pass the
declaration because it is also used for the function variable of a named
function expression, which doesn't have a declaration object. I will leave
cleaning this up for another hypothetical CL.
On 2011/10/24 12:58:13, fschneider wrote:
> EmitDeclaration is used in two places. Is it possible to use
> variable->binding_needs_init() instead here?

http://codereview.chromium.org/7992005/diff/23028/src/runtime.cc
File src/runtime.cc (right):

http://codereview.chromium.org/7992005/diff/23028/src/runtime.cc#newcode8880
src/runtime.cc:8880: UNREACHABLE();
On 2011/10/24 12:58:13, fschneider wrote:
> Not sure, but you may have to return something here to make the compiler
happy.

Done.

[fschneider, 2011-10-24 15:33:43]

Still LGTM.

http://codereview.chromium.org/7992005/diff/23028/src/ia32/full-codegen-ia32.cc
File src/ia32/full-codegen-ia32.cc (right):

http://codereview.chromium.org/7992005/diff/23028/src/ia32/full-codegen-ia32....
src/ia32/full-codegen-ia32.cc:714: bool binding_needs_init =
Yes, passing a declaration object would be the right way, but it's fine to leave
it as is for this change.

On 2011/10/24 14:05:18, Steven wrote:
> Unfortunately for DYNAMIC_GLOBAL variables we can only get the mode used in
the
> declaration from the declaration object and not from the variable itself. It
> does for example occur with eval('var foo;') in global scope. We can't pass
the
> declaration because it is also used for the function variable of a named
> function expression, which doesn't have a declaration object. I will leave
> cleaning this up for another hypothetical CL.
> On 2011/10/24 12:58:13, fschneider wrote:
> > EmitDeclaration is used in two places. Is it possible to use
> > variable->binding_needs_init() instead here?
>