[strong] Declaration-after-use errors.

[strong] Declaration-after-use errors.

We cannot yet detect use-before-declaration in general, because for that we'd
need to analyze the context when compiling. But we can detect an error case
where we first see a use, then a declaration.

For this, I also added end position tracking (needed for error messages) to
VariableProxy.

Note: the position naming is completely inconsistent: start_position &
end_position, position & end_position, pos & end_pos, beg_pos & end_pos, to name
a few. This doesn't fix all of it, but tries to unify towards start_position &
end_position whenever possible w/ minimal changes.

BUG=

Committed: https://crrev.com/1eddcf5b712c4a3c366a9a011e5b5b61a9f78315
Cr-Commit-Position: refs/heads/master@{#26880}

[marja, 2015-02-20 12:21:03]

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

[marja, 2015-02-20 12:44:46]

rossberg, ptal.

adamk, fyi, this conflicts w/ your error handling changes, I can rebase once you
land your CL.

[marja, 2015-02-20 13:22:09]

Ah, nevermind, this is not working, no need to have a look before I fix it...

[marja, 2015-02-23 12:37:52]

(all fixed now, ptal)

[rossberg, 2015-02-23 13:45:26]

https://codereview.chromium.org/943543002/diff/180001/src/ast.h
File src/ast.h (right):

https://codereview.chromium.org/943543002/diff/180001/src/ast.h#newcode1658
src/ast.h:1658: VariableProxy(Zone* zone, Variable* var, int start_position,
You could pass a Location instead of the individual values.

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

https://codereview.chromium.org/943543002/diff/180001/src/parser.cc#newcode3753
src/parser.cc:3753: Variable::FUNCTION, kCreatedInitialized, kNotAssigned);
Note that this is not a function declaration, but a local binding that is always
initialised immediately. I don't think it requires special treatment as a
function.

https://codereview.chromium.org/943543002/diff/180001/src/scopes.cc
File src/scopes.cc (right):

https://codereview.chromium.org/943543002/diff/180001/src/scopes.cc#newcode1078
src/scopes.cc:1078: // they are inside the same eval scope or different ones.
Can you add a TODO regarding different evals? I suppose each direct eval scope
somehow would need to know its call position in the outer program text... Hm,
tricky... I think we want to disallow direct eval in strong mode anyway, but
that still leaves toplevel bindings.

https://codereview.chromium.org/943543002/diff/180001/src/scopes.cc#newcode1084
src/scopes.cc:1084: proxy->position() < var->position() && !var->is_function()
&&
I don't believe this is good enough. Consider:

  let x = x+1

Here, proxy->pos > var->pos, but it's an error nonetheless.

We already have var->initializer_position, which marks the position where a var
is known to be bound (and is used by codegen to eliminate unnecessary hole
checks for lexical bindings, see e.g. full-codegen-ia32.cc:1474). In the above
case that would point at the _end_ of the binding's RHS (but before the next
binding, if there are multiple comma-separated ones).

However, you probably need to set that position properly for a couple more
declaration forms now (previously it only mattered for lexical ones). Also, I
just saw that it seems wrong in ParseClassDeclaration.

https://codereview.chromium.org/943543002/diff/180001/test/mjsunit/strong/dec...
File test/mjsunit/strong/declaration-after-use.js (right):

https://codereview.chromium.org/943543002/diff/180001/test/mjsunit/strong/dec...
test/mjsunit/strong/declaration-after-use.js:7: (function DeclarationAfterUse()
{
More tests would be great, both positive and negative. In particular:

- different combinations of multi-bindings with uses on the RHS
- class declarations referring to themselves in different parts
- for loops

[arv (Not doing code reviews), 2015-02-23 14:45:54]

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

[arv (Not doing code reviews), 2015-02-23 14:45:55]

https://codereview.chromium.org/943543002/diff/180001/src/variables.h
File src/variables.h (right):

https://codereview.chromium.org/943543002/diff/180001/src/variables.h#newcode21
src/variables.h:21: enum Kind { NORMAL, FUNCTION, THIS, NEW_TARGET, ARGUMENTS };
I find this change strange. How is FUNCTION related to the other ones?

[marja, 2015-02-24 13:28:04]

Patchset #16 (id:300001) has been deleted

[marja, 2015-02-24 13:29:35]

thanks for having a look

https://codereview.chromium.org/943543002/diff/180001/src/ast.h
File src/ast.h (right):

https://codereview.chromium.org/943543002/diff/180001/src/ast.h#newcode1658
src/ast.h:1658: VariableProxy(Zone* zone, Variable* var, int start_position,
On 2015/02/23 13:45:26, rossberg wrote:
> You could pass a Location instead of the individual values.

As discussed offline: Didn't do this change because Location is an inner class
of Scanner, and making ast.h include scanner.h makes no sense. Location ofc
shouldn't be an inner class of Scanner, but I won't fix that in this CL.

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

https://codereview.chromium.org/943543002/diff/180001/src/parser.cc#newcode3753
src/parser.cc:3753: Variable::FUNCTION, kCreatedInitialized, kNotAssigned);
On 2015/02/23 13:45:26, rossberg wrote:
> Note that this is not a function declaration, but a local binding that is
always
> initialised immediately. I don't think it requires special treatment as a
> function.

Done, in addition did the same change in Scope::LookupFunctionVar, I don't think
we need that to be Variable::FUNCTION either (but I'm not 100% sure about that).

https://codereview.chromium.org/943543002/diff/180001/src/scopes.cc
File src/scopes.cc (right):

https://codereview.chromium.org/943543002/diff/180001/src/scopes.cc#newcode1078
src/scopes.cc:1078: // they are inside the same eval scope or different ones.
On 2015/02/23 13:45:26, rossberg wrote:
> Can you add a TODO regarding different evals? I suppose each direct eval scope
> somehow would need to know its call position in the outer program text... Hm,
> tricky... I think we want to disallow direct eval in strong mode anyway, but
> that still leaves toplevel bindings.

Added a todo.

So one error case is:

This throws:
"use strong"; eval("let x = 1;"); eval("x;")

But this doesn't:
"use strong"; eval("let x = 1;"); eval("if (false) { x; }");

But won't we need the context analysis for that anyway?

https://codereview.chromium.org/943543002/diff/180001/src/scopes.cc#newcode1084
src/scopes.cc:1084: proxy->position() < var->position() && !var->is_function()
&&
On 2015/02/23 13:45:26, rossberg wrote:
> I don't believe this is good enough. Consider:
> 
>   let x = x+1
> 
> Here, proxy->pos > var->pos, but it's an error nonetheless.
> 
> We already have var->initializer_position, which marks the position where a
var
> is known to be bound (and is used by codegen to eliminate unnecessary hole
> checks for lexical bindings, see e.g. full-codegen-ia32.cc:1474). In the above
> case that would point at the _end_ of the binding's RHS (but before the next
> binding, if there are multiple comma-separated ones).
> 
> However, you probably need to set that position properly for a couple more
> declaration forms now (previously it only mattered for lexical ones). Also, I
> just saw that it seems wrong in ParseClassDeclaration.

Fixed this to use initializer_position(), undid the position addition to
Variable, fixed a couple of places where the initializer position was set, added
test cases.

https://codereview.chromium.org/943543002/diff/180001/src/variables.h
File src/variables.h (right):

https://codereview.chromium.org/943543002/diff/180001/src/variables.h#newcode21
src/variables.h:21: enum Kind { NORMAL, FUNCTION, THIS, NEW_TARGET, ARGUMENTS };
On 2015/02/23 14:45:55, arv wrote:
> I find this change strange. How is FUNCTION related to the other ones?

The previous NORMAL is split into NORMAL and FUNCTION, to distinguish
declarations like:

let x = 0; // NORMAL

from

function x() { } // FUNCTION

In addition:

let x = function() { ..} // NORMAL

This is needed so that we can make this work:

function foo() {
  bar; // ok
  bar2; // not ok
}

function bar() { }
let bar2 = 0;

... it's not necessary that this information is carried in the Kind; but it
seemed suitable since nothing checked for == NORMAL (only == THIS, ==
ARGUMENTS), so splitting NORMAL was feasible, and, I don't fully understand what
exactly this "Kind" is, except intuitively "it's what kind of a variable it is",
and for that, function seemed a suitable addition.

https://codereview.chromium.org/943543002/diff/180001/test/mjsunit/strong/dec...
File test/mjsunit/strong/declaration-after-use.js (right):

https://codereview.chromium.org/943543002/diff/180001/test/mjsunit/strong/dec...
test/mjsunit/strong/declaration-after-use.js:7: (function DeclarationAfterUse()
{
On 2015/02/23 13:45:26, rossberg wrote:
> More tests would be great, both positive and negative. In particular:
> 
> - different combinations of multi-bindings with uses on the RHS
> - class declarations referring to themselves in different parts
> - for loops

Added some tests here, probably not everything you had in mind.

[rossberg, 2015-02-24 15:52:40]

https://codereview.chromium.org/943543002/diff/320001/src/parser.cc
File src/parser.cc (right):

https://codereview.chromium.org/943543002/diff/320001/src/parser.cc#newcode1820
src/parser.cc:1820: name, mode, declaration->initialization(),
declaration->position(),
Hm, I'm confused, why is this the right init position?

https://codereview.chromium.org/943543002/diff/320001/src/parser.cc#newcode2039
src/parser.cc:2039: proxy->var()->set_initializer_position(pos);
I'm surprised that this isn't a problem, since 'pos' doesn't seem to point at
the right position.

https://codereview.chromium.org/943543002/diff/320001/test/mjsunit/strong/dec...
File test/mjsunit/strong/declaration-after-use.js (right):

https://codereview.chromium.org/943543002/diff/320001/test/mjsunit/strong/dec...
test/mjsunit/strong/declaration-after-use.js:68: "'use strong'; if (false) { for
(let x = x; ; ) { } }",
Perhaps add

  for (let x = y, y; ;) {}

https://codereview.chromium.org/943543002/diff/320001/test/mjsunit/strong/dec...
test/mjsunit/strong/declaration-after-use.js:77: assertThrowsHelper("'use
strong'; if (false) { class C extends C { } }",
Also add versions for class expressions:

  let C = class C2 extends C2 {}
  let C = class extends C {}

Also, with --harmony-computed-property-names, the following ones become
relevant:

  class C { [C]() {} }
  class C { get [C]() {} }
  class C { set [C]() {} }
  class C { static [C]() {} }

https://codereview.chromium.org/943543002/diff/320001/test/mjsunit/strong/dec...
test/mjsunit/strong/declaration-after-use.js:98: for (let var4a = 0, var4b = 0;
var4a + var4b < 4; var4a++, var4b++) {
Change to

  var4b = var4a

https://codereview.chromium.org/943543002/diff/320001/test/mjsunit/strong/dec...
test/mjsunit/strong/declaration-after-use.js:142: class C { constructor() { C; }
};
Add a

  new C

after.

[marja, 2015-02-24 18:05:41]

https://codereview.chromium.org/943543002/diff/320001/src/parser.cc
File src/parser.cc (right):

https://codereview.chromium.org/943543002/diff/320001/src/parser.cc#newcode1820
src/parser.cc:1820: name, mode, declaration->initialization(),
declaration->position(),
On 2015/02/24 15:52:40, rossberg wrote:
> Hm, I'm confused, why is this the right init position?

Argh, this was only working because the position is fixed later w/
set_initializer_position. The only case where this position actually got used
(was not overwritten) was for "var", and for those, there were (are?) no test
cases where the difference would matter. (Like, var x = x + 1; is ok and we
don't allow those in strong mode anyway.)

So I removed transmitting the declaration position altogether and made var
variables also have their initializer positions set. This is needed so that we
can make this an error: function foo() {"use strong"; x; } var x = 0;

https://codereview.chromium.org/943543002/diff/320001/src/parser.cc#newcode2039
src/parser.cc:2039: proxy->var()->set_initializer_position(pos);
On 2015/02/24 15:52:40, rossberg wrote:
> I'm surprised that this isn't a problem, since 'pos' doesn't seem to point at
> the right position.

This isn't the problem for the

class C extends C { }

case, because the relevant declaration is done by ParseClassLiteral, not this
function. (Both ParseClassDeclaration and ParseClassLiteral declare C, but the
stuff inside the class resolves to what ParseClassLiteral declared.)

IOW, I didn't see a place where this position set here would matter, so I didn't
change it.

https://codereview.chromium.org/943543002/diff/320001/test/mjsunit/strong/dec...
File test/mjsunit/strong/declaration-after-use.js (right):

https://codereview.chromium.org/943543002/diff/320001/test/mjsunit/strong/dec...
test/mjsunit/strong/declaration-after-use.js:68: "'use strong'; if (false) { for
(let x = x; ; ) { } }",
On 2015/02/24 15:52:40, rossberg wrote:
> Perhaps add
> 
>   for (let x = y, y; ;) {}

Done.

https://codereview.chromium.org/943543002/diff/320001/test/mjsunit/strong/dec...
test/mjsunit/strong/declaration-after-use.js:77: assertThrowsHelper("'use
strong'; if (false) { class C extends C { } }",
On 2015/02/24 15:52:40, rossberg wrote:
> Also add versions for class expressions:
> 
>   let C = class C2 extends C2 {}
>   let C = class extends C {}
> 
> Also, with --harmony-computed-property-names, the following ones become
> relevant:
> 
>   class C { [C]() {} }
>   class C { get [C]() {} }
>   class C { set [C]() {} }
>   class C { static [C]() {} }

Added the first 2 cases and a TODO for computed property names (difficult!).

https://codereview.chromium.org/943543002/diff/320001/test/mjsunit/strong/dec...
test/mjsunit/strong/declaration-after-use.js:98: for (let var4a = 0, var4b = 0;
var4a + var4b < 4; var4a++, var4b++) {
On 2015/02/24 15:52:40, rossberg wrote:
> Change to
> 
>   var4b = var4a

Done.

https://codereview.chromium.org/943543002/diff/320001/test/mjsunit/strong/dec...
test/mjsunit/strong/declaration-after-use.js:142: class C { constructor() { C; }
};
On 2015/02/24 15:52:40, rossberg wrote:
> Add a
> 
>   new C
> 
> after.

Done.

[rossberg, 2015-02-25 13:17:27]

lgtm

https://codereview.chromium.org/943543002/diff/320001/src/parser.cc
File src/parser.cc (right):

https://codereview.chromium.org/943543002/diff/320001/src/parser.cc#newcode2039
src/parser.cc:2039: proxy->var()->set_initializer_position(pos);
On 2015/02/24 18:05:40, marja wrote:
> On 2015/02/24 15:52:40, rossberg wrote:
> > I'm surprised that this isn't a problem, since 'pos' doesn't seem to point
at
> > the right position.
> 
> This isn't the problem for the
> 
> class C extends C { }
> 
> case, because the relevant declaration is done by ParseClassLiteral, not this
> function. (Both ParseClassDeclaration and ParseClassLiteral declare C, but the
> stuff inside the class resolves to what ParseClassLiteral declared.)
> 
> IOW, I didn't see a place where this position set here would matter, so I
didn't
> change it.

I see, because it is immediately shadowed in the class-expr on the RHS. Subtle.

I'd still prefer the position on the let-variable to be consistent with other
let-bindings. I.e., just set it to position().

[marja, 2015-02-25 13:25:03]

thanks for review!

(arv, more comments?)

https://codereview.chromium.org/943543002/diff/320001/src/parser.cc
File src/parser.cc (right):

https://codereview.chromium.org/943543002/diff/320001/src/parser.cc#newcode2039
src/parser.cc:2039: proxy->var()->set_initializer_position(pos);
On 2015/02/25 13:17:27, rossberg wrote:
> On 2015/02/24 18:05:40, marja wrote:
> > On 2015/02/24 15:52:40, rossberg wrote:
> > > I'm surprised that this isn't a problem, since 'pos' doesn't seem to point
> at
> > > the right position.
> > 
> > This isn't the problem for the
> > 
> > class C extends C { }
> > 
> > case, because the relevant declaration is done by ParseClassLiteral, not
this
> > function. (Both ParseClassDeclaration and ParseClassLiteral declare C, but
the
> > stuff inside the class resolves to what ParseClassLiteral declared.)
> > 
> > IOW, I didn't see a place where this position set here would matter, so I
> didn't
> > change it.
> 
> I see, because it is immediately shadowed in the class-expr on the RHS.
Subtle.
> 
> I'd still prefer the position on the let-variable to be consistent with other
> let-bindings. I.e., just set it to position().

Okay, did that. So here position() is at the end of the class body... first I
thought that it wouldn't make sense, and we'd want to set the position to the
same as the other C variable's position (i.e., after "class C extends Foo"), but
maybe that's not true. At least position() is less wrong here than pos.

[rossberg, 2015-02-25 13:29:08]

https://codereview.chromium.org/943543002/diff/320001/src/parser.cc
File src/parser.cc (right):

https://codereview.chromium.org/943543002/diff/320001/src/parser.cc#newcode2039
src/parser.cc:2039: proxy->var()->set_initializer_position(pos);
On 2015/02/25 13:25:03, marja wrote:
> On 2015/02/25 13:17:27, rossberg wrote:
> > On 2015/02/24 18:05:40, marja wrote:
> > > On 2015/02/24 15:52:40, rossberg wrote:
> > > > I'm surprised that this isn't a problem, since 'pos' doesn't seem to
point
> > at
> > > > the right position.
> > > 
> > > This isn't the problem for the
> > > 
> > > class C extends C { }
> > > 
> > > case, because the relevant declaration is done by ParseClassLiteral, not
> this
> > > function. (Both ParseClassDeclaration and ParseClassLiteral declare C, but
> the
> > > stuff inside the class resolves to what ParseClassLiteral declared.)
> > > 
> > > IOW, I didn't see a place where this position set here would matter, so I
> > didn't
> > > change it.
> > 
> > I see, because it is immediately shadowed in the class-expr on the RHS.
> Subtle.
> > 
> > I'd still prefer the position on the let-variable to be consistent with
other
> > let-bindings. I.e., just set it to position().
> 
> Okay, did that. So here position() is at the end of the class body... first I
> thought that it wouldn't make sense, and we'd want to set the position to the
> same as the other C variable's position (i.e., after "class C extends Foo"),
but
> maybe that's not true. At least position() is less wrong here than pos.

Why, the outer C is a completely separate variable -- its position should be
exactly what you'd get if you were writing the above desugaring

  let C = class C {...};

manually.

[marja, 2015-02-25 13:31:12]

Yeah, it makes sense taken into account which references resolve to the "inner"
and "outer" C's.

[marja, 2015-02-25 14:33:34]

Patchset #21 (id:360002) has been deleted

[arv (Not doing code reviews), 2015-02-25 16:37:32]

LGTM

My comments can be resolved after this CL lands if you prefer.

https://codereview.chromium.org/943543002/diff/420001/src/parser.cc
File src/parser.cc (right):

https://codereview.chromium.org/943543002/diff/420001/src/parser.cc#newcode2240
src/parser.cc:2240: DCHECK(var != nullptr);
DCHECK_NOT_NULL

https://codereview.chromium.org/943543002/diff/420001/src/parser.cc#newcode2298
src/parser.cc:2298: // Record the end position of the initializer.
Maybe move this comment to before the if since it is same for both branches.

https://codereview.chromium.org/943543002/diff/420001/src/scopes.cc
File src/scopes.cc (right):

https://codereview.chromium.org/943543002/diff/420001/src/scopes.cc#newcode1081
src/scopes.cc:1081: // ones. TODO(marja,rossberg): Detect errors across
different evals
Move TODO to new line?

https://codereview.chromium.org/943543002/diff/420001/src/scopes.h
File src/scopes.h (right):

https://codereview.chromium.org/943543002/diff/420001/src/scopes.h#newcode134
src/scopes.h:134: InitializationFlag init_flag, bool is_function,
Maybe use Variable::Kind here instead of the boolean?

https://codereview.chromium.org/943543002/diff/420001/test/mjsunit/strong/dec...
File test/mjsunit/strong/declaration-after-use.js (right):

https://codereview.chromium.org/943543002/diff/420001/test/mjsunit/strong/dec...
test/mjsunit/strong/declaration-after-use.js:82: })();
Maybe test for-of loops too?

https://codereview.chromium.org/943543002/diff/420001/test/mjsunit/strong/dec...
test/mjsunit/strong/declaration-after-use.js:100: "'use strong'; if (false) {
let C = class C2 { method() { C; } } }",
This is kind of weird.

What about?

let f = function g() {
  g;  // Error or not?
};

https://codereview.chromium.org/943543002/diff/420001/test/mjsunit/strong/dec...
test/mjsunit/strong/declaration-after-use.js:104: // tests.
I'm surprised that doesn't work already?

[arv (Not doing code reviews), 2015-02-25 16:49:18]

https://codereview.chromium.org/943543002/diff/420001/test/mjsunit/strong/dec...
File test/mjsunit/strong/declaration-after-use.js (right):

https://codereview.chromium.org/943543002/diff/420001/test/mjsunit/strong/dec...
test/mjsunit/strong/declaration-after-use.js:100: "'use strong'; if (false) {
let C = class C2 { method() { C; } } }",
On 2015/02/25 16:37:32, arv wrote:
> This is kind of weird.
> 
> What about?
> 
> let f = function g() {
>   g;  // Error or not?
> };

I realized I misread this one.

I see you already have test for:

(class C { constructor() { C; } });

but I don't see anything for:

(function f() { f; });

[marja, 2015-02-26 12:55:42]

thanks for review!

https://codereview.chromium.org/943543002/diff/420001/src/parser.cc
File src/parser.cc (right):

https://codereview.chromium.org/943543002/diff/420001/src/parser.cc#newcode2240
src/parser.cc:2240: DCHECK(var != nullptr);
On 2015/02/25 16:37:32, arv wrote:
> DCHECK_NOT_NULL

Done.

https://codereview.chromium.org/943543002/diff/420001/src/parser.cc#newcode2298
src/parser.cc:2298: // Record the end position of the initializer.
On 2015/02/25 16:37:32, arv wrote:
> Maybe move this comment to before the if since it is same for both branches.

Hmm, that's kinda far away... instead, I made these comments more useful by
clarifying why the end positions are different in these 2 cases.

https://codereview.chromium.org/943543002/diff/420001/src/scopes.cc
File src/scopes.cc (right):

https://codereview.chromium.org/943543002/diff/420001/src/scopes.cc#newcode1081
src/scopes.cc:1081: // ones. TODO(marja,rossberg): Detect errors across
different evals
On 2015/02/25 16:37:32, arv wrote:
> Move TODO to new line?

Done.

https://codereview.chromium.org/943543002/diff/420001/src/scopes.h
File src/scopes.h (right):

https://codereview.chromium.org/943543002/diff/420001/src/scopes.h#newcode134
src/scopes.h:134: InitializationFlag init_flag, bool is_function,
On 2015/02/25 16:37:32, arv wrote:
> Maybe use Variable::Kind here instead of the boolean?

Done.

https://codereview.chromium.org/943543002/diff/420001/test/mjsunit/strong/dec...
File test/mjsunit/strong/declaration-after-use.js (right):

https://codereview.chromium.org/943543002/diff/420001/test/mjsunit/strong/dec...
test/mjsunit/strong/declaration-after-use.js:82: })();
On 2015/02/25 16:37:32, arv wrote:
> Maybe test for-of loops too?

Not sure what cases you meant exactly; I thought maybe:

'use strong'; if (false) { for (let x of x) { } }

But that is not an error because the latter x resolves to the global scope. For
example this works:

"use strict"; var x = [1,2]; for (let x of x) { print(x); }

https://codereview.chromium.org/943543002/diff/420001/test/mjsunit/strong/dec...
test/mjsunit/strong/declaration-after-use.js:100: "'use strong'; if (false) {
let C = class C2 { method() { C; } } }",
On 2015/02/25 16:49:18, arv wrote:
> On 2015/02/25 16:37:32, arv wrote:
> > This is kind of weird.
> > 
> > What about?
> > 
> > let f = function g() {
> >   g;  // Error or not?
> > };
> 
> I realized I misread this one.
> 
> I see you already have test for:
> 
> (class C { constructor() { C; } });
> 
> but I don't see anything for:
> 
> (function f() { f; });

Isn't the func1 test below testing this sufficiently:

  function func1() { func1; this; }

https://codereview.chromium.org/943543002/diff/420001/test/mjsunit/strong/dec...
test/mjsunit/strong/declaration-after-use.js:104: // tests.
On 2015/02/25 16:37:32, arv wrote:
> I'm surprised that doesn't work already?

The basic case works (added it above):

'use strong'; if (false) { let o = { 'a': 'b', [o.a]: 'c'}; }

And one case for referencing a let declared class in a computed property name:

'use strong'; if (false) {
   let C = class C2 { 
     static a() { return 'A'; }
     [C.a()]() { return 'B'; } // C shouldn't be allowed here
   };
}

rossberg@ thought there are prob some corner cases where we don't detect errors
w/ the class name even though we should, thus the TODO to sort that out later.

[marja, 2015-02-26 12:58:14]

The CQ bit was checked by marja@chromium.org

[marja, 2015-02-26 12:58:14]

The patchset sent to the CQ was uploaded after l-g-t-m from
rossberg@chromium.org, arv@chromium.org
Link to the patchset: https://codereview.chromium.org/943543002/#ps440001
(title: ".")

[commit-bot: I haz the power, 2015-02-26 12:58:54]

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

[marja, 2015-02-26 13:23:59]

The CQ bit was unchecked by marja@chromium.org

[marja, 2015-02-26 13:25:28]

The CQ bit was checked by marja@chromium.org

[marja, 2015-02-26 13:25:29]

The patchset sent to the CQ was uploaded after l-g-t-m from arv@chromium.org,
rossberg@chromium.org
Link to the patchset: https://codereview.chromium.org/943543002/#ps460001
(title: "computed prop names comment fix")

[commit-bot: I haz the power, 2015-02-26 13:26:16]

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

[commit-bot: I haz the power, 2015-02-26 13:48:17]

Committed patchset #23 (id:460001)

[commit-bot: I haz the power, 2015-02-26 13:48:29]

Patchset 23 (id:??) landed as
https://crrev.com/1eddcf5b712c4a3c366a9a011e5b5b61a9f78315
Cr-Commit-Position: refs/heads/master@{#26880}