Refactor class declaration logic to the parser and runtime

Refactor class declaration logic to the parser and runtime.

ClassDeclarations and Expressions had a first-class representation in
the AST, with implementations in all of the backends. This involved a
significant amount of substantially-duplicated code, and made future
changes and maintenance much harder than it needed to be. This CL
modifies the parser to produce a DoExpression which calls out to a
runtime function, DefineClass, which installs the given properties on
the constructor and its prototype. DoExpressions AST nodes gain a new
field to enable function name inference for class expressions.

This comes at a roughly ten percent slowdown in both class parsing and
execution in the worst case. Instantiation is not discernibly affected.

[bakkot, 2016-07-12 23:17:29]

The CQ bit was checked by bakkot@google.com to run a CQ dry run

[commit-bot: I haz the power, 2016-07-12 23:17:36]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-12 23:22:26]

The CQ bit was unchecked by commit-bot@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-12 23:22:27]

Dry run: Try jobs failed on following builders:
  v8_linux_nodcheck_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_nodcheck_rel_ng/bu...)

[bakkot, 2016-07-12 23:49:18]

The CQ bit was checked by bakkot@google.com to run a CQ dry run

[commit-bot: I haz the power, 2016-07-12 23:49:22]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-13 00:04:01]

The CQ bit was unchecked by commit-bot@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-13 00:04:02]

Dry run: Try jobs failed on following builders:
  v8_linux64_avx2_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel_ng/buil...)
  v8_linux64_avx2_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel_ng_trig...)

[bakkot, 2016-07-13 00:08:39]

The CQ bit was checked by bakkot@google.com to run a CQ dry run

[commit-bot: I haz the power, 2016-07-13 00:08:43]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-13 00:20:51]

The CQ bit was unchecked by commit-bot@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-13 00:20:52]

Dry run: Try jobs failed on following builders:
  v8_linux64_avx2_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel_ng/buil...)
  v8_linux64_avx2_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel_ng_trig...)

[bakkot, 2016-07-13 00:30:09]

The CQ bit was checked by bakkot@google.com to run a CQ dry run

[commit-bot: I haz the power, 2016-07-13 00:30:15]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-13 00:52:31]

The CQ bit was unchecked by commit-bot@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-13 00:52:32]

Dry run: This issue passed the CQ dry run.

[bakkot, 2016-07-13 16:34:16]

Description was changed from

==========
Refactor class declaration logic to the parser and runtime.

ClassDeclarations and Expressions had a first-class representation in
the AST, with implementations in all of the backends. This involved a
significant amount of substantially-duplicated code, and made future
changes and maintenance much harder than it needed to be. This CL
modifies the parser to produce a DoExpression which calls out to a
runtime function, DefineClass, which installs the given properties on
the constructor and its prototype. DoExpressions AST nodes gain a new
field to enable function name inference for class expressions.

This comes at a roughly ten percent slowdown in the worst case.
==========

to

==========
Refactor class declaration logic to the parser and runtime.

ClassDeclarations and Expressions had a first-class representation in
the AST, with implementations in all of the backends. This involved a
significant amount of substantially-duplicated code, and made future
changes and maintenance much harder than it needed to be. This CL
modifies the parser to produce a DoExpression which calls out to a
runtime function, DefineClass, which installs the given properties on
the constructor and its prototype. DoExpressions AST nodes gain a new
field to enable function name inference for class expressions.

This comes at a roughly ten percent slowdown in both class parsing and
execution in the worst case. Instantiation is not discernibly affected.
==========

[bakkot, 2016-07-13 16:34:17]

bakkot@google.com changed reviewers:
+ adamk@chromium.org, littledan@chromium.org

[bakkot, 2016-07-13 18:18:19]

Please add other reviewers as necessary.

[adamk, 2016-07-13 20:57:33]

First round of comments, will need more reading to better grok the whole thing,
but this at least has a suggestion for improving performance.

https://codereview.chromium.org/2142333002/diff/80001/src/parsing/parser.cc
File src/parsing/parser.cc (right):

https://codereview.chromium.org/2142333002/diff/80001/src/parsing/parser.cc#n...
src/parsing/parser.cc:5017: auto prop_pos =
The general practice in v8 has been to use "auto" only where the type is
obvious, which isn't the case here. Also "int" is shorter :)

Also, I'd name this "property_pos", you already have several variables with a
"property_" prefix.

https://codereview.chromium.org/2142333002/diff/80001/src/parsing/parser.cc#n...
src/parsing/parser.cc:5018:
GetPropertyValue(property)->AsFunctionLiteral()->position();
GetPropertyValue() isn't needed here, you already pulled the value out on the
next line. Don't need the AsFunctionLiteral() either, all Expressions have a
position().

https://codereview.chromium.org/2142333002/diff/80001/src/parsing/parser.cc#n...
src/parsing/parser.cc:5023: if (property_name != nullptr) {
For the common case of non-numeric properties, you can add an extra if before
this:

if (property->key()->IsStringLiteral()) {
  property_key = property->key();
} else if (property_name != nullptr) {
  // handle the smi case as you're already doing
} else {
  // handle the computed case
}

https://codereview.chromium.org/2142333002/diff/80001/src/parsing/parser.cc#n...
src/parsing/parser.cc:5027: ZoneList<Expression*>* toName_args =
Style nit: to_name_args

https://codereview.chromium.org/2142333002/diff/80001/src/parsing/parser.cc#n...
src/parsing/parser.cc:5032: factory()->NewCallRuntime(Runtime::kToName,
toName_args, prop_pos);
You can use kInlineToName, which in TurboFan will be much faster and elsewhere
will fall back to the runtime.

https://codereview.chromium.org/2142333002/diff/80001/src/runtime/runtime-cla...
File src/runtime/runtime-classes.cc (right):

https://codereview.chromium.org/2142333002/diff/80001/src/runtime/runtime-cla...
src/runtime/runtime-classes.cc:185: JSReceiver::GetElement(isolate,
property_names, i).ToHandleChecked();
These are probably one of the reasons this is slow. You're going through all the
machinery of property access.

One thing to try, at least to see if it speeds this up, is to access elements()
backing store directly, though of course this is a little scary. See
EstimateElementCount in builtins.cc for some example code (good enough at least
to try out for performance).

[adamk, 2016-07-14 00:47:43]

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

[commit-bot: I haz the power, 2016-07-14 00:47:56]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-14 00:49:24]

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

[commit-bot: I haz the power, 2016-07-14 00:49:25]

Dry run: Try jobs failed on following builders:
  v8_linux64_avx2_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel_ng/buil...)
  v8_linux_arm64_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm64_rel_ng/build...)

[bakkot, 2016-07-14 17:07:46]

The CQ bit was checked by bakkot@google.com to run a CQ dry run

[commit-bot: I haz the power, 2016-07-14 17:07:48]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-14 17:10:58]

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

[commit-bot: I haz the power, 2016-07-14 17:10:59]

Dry run: Try jobs failed on following builders:
  v8_linux_arm_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm_rel_ng/builds/...)
  v8_mac_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_mac_rel_ng/builds/5062)

[bakkot, 2016-07-14 17:14:10]

The CQ bit was checked by bakkot@google.com to run a CQ dry run

[commit-bot: I haz the power, 2016-07-14 17:14:18]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-14 17:26:29]

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

[commit-bot: I haz the power, 2016-07-14 17:26:30]

Dry run: Try jobs failed on following builders:
  v8_linux64_gyp_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_gyp_rel_ng/build...)
  v8_linux64_gyp_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_gyp_rel_ng_trigg...)

[bakkot, 2016-07-14 17:28:59]

The CQ bit was unchecked by bakkot@google.com

[bakkot, 2016-07-14 17:36:27]

The CQ bit was checked by bakkot@google.com to run a CQ dry run

[commit-bot: I haz the power, 2016-07-14 17:36:33]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-14 17:48:29]

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

[commit-bot: I haz the power, 2016-07-14 17:48:30]

Dry run: Try jobs failed on following builders:
  v8_linux64_gyp_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_gyp_rel_ng/build...)
  v8_linux64_gyp_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_gyp_rel_ng_trigg...)

[bakkot, 2016-07-14 21:47:53]

The CQ bit was checked by bakkot@google.com to run a CQ dry run

[commit-bot: I haz the power, 2016-07-14 21:47:58]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-14 22:00:42]

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

[commit-bot: I haz the power, 2016-07-14 22:00:44]

Dry run: Try jobs failed on following builders:
  v8_linux64_gyp_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_gyp_rel_ng/build...)
  v8_linux64_gyp_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_gyp_rel_ng_trigg...)

[adamk, 2016-07-14 22:00:46]

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

[adamk, 2016-07-14 22:00:48]

Adding bmeurer as a reviewer (and CC mstarzinger) for compiler thoughts on this;
he'd indicated interest in desugaring classes some time ago (will be needed for
OWNERS as well).

My high level thoughts is that while this deletes a lot of code, it also removes
the ability for the optimizing compilers to do much: all the interesting logic
happens in the runtime function. So I'm interested to see what Benedikt's take
on that is.

https://codereview.chromium.org/2142333002/diff/100001/src/parsing/parser.cc
File src/parsing/parser.cc (right):

https://codereview.chromium.org/2142333002/diff/100001/src/parsing/parser.cc#...
src/parsing/parser.cc:5088: Block* do_block = factory()->NewBlock(nullptr, 16,
false, pos);
s/16/1/ I think (looks like this block only contains a single statement?)

https://codereview.chromium.org/2142333002/diff/100001/src/parsing/parser.cc#...
src/parsing/parser.cc:5134: Expression* fast_properties_call =
factory()->NewCallRuntime(
Probably worth adding a comment that kToFastProperties returns its argument, I
had to read the block below several times to understand what it was doing.

https://codereview.chromium.org/2142333002/diff/180001/src/asmjs/typing-asm.cc
File src/asmjs/typing-asm.cc (right):

https://codereview.chromium.org/2142333002/diff/180001/src/asmjs/typing-asm.c...
src/asmjs/typing-asm.cc:1: // Copyright 2015 the V8 project authors. All rights
reserved.
Did this file get accidentally added as part of some rebase?

https://codereview.chromium.org/2142333002/diff/180001/src/ast/ast-numbering.cc
File src/ast/ast-numbering.cc (left):

https://codereview.chromium.org/2142333002/diff/180001/src/ast/ast-numbering....
src/ast/ast-numbering.cc:468: DisableCrankshaft(kClassLiteral);
I have another guess for why this got slower. I wonder if you're going through
Crankshaft where previously you were going through TurboFan? And because this is
all implemented as runtime calls you're no longer getting any optimization when
you hit the optimizer.

https://codereview.chromium.org/2142333002/diff/180001/src/ast/ast.cc
File src/ast/ast.cc (left):

https://codereview.chromium.org/2142333002/diff/180001/src/ast/ast.cc#oldcode375
src/ast/ast.cc:375: void ClassLiteral::AssignFeedbackVectorSlots(Isolate*
isolate,
Seems possibly bad that we're losing these now, something to investigate (with
help from mvstanton@ most likely).

https://codereview.chromium.org/2142333002/diff/180001/src/parsing/parameter-...
File src/parsing/parameter-initializer-rewriter.cc (left):

https://codereview.chromium.org/2142333002/diff/180001/src/parsing/parameter-...
src/parsing/parameter-initializer-rewriter.cc:114: else
Why does this else go away?

[bakkot, 2016-07-14 22:03:18]

The CQ bit was unchecked by bakkot@google.com

[bakkot, 2016-07-14 22:46:01]

https://codereview.chromium.org/2142333002/diff/100001/src/parsing/parser.cc
File src/parsing/parser.cc (right):

https://codereview.chromium.org/2142333002/diff/100001/src/parsing/parser.cc#...
src/parsing/parser.cc:5088: Block* do_block = factory()->NewBlock(nullptr, 16,
false, pos);
On 2016/07/14 at 22:00:47, adamk wrote:
> s/16/1/ I think (looks like this block only contains a single statement?)

Done.

https://codereview.chromium.org/2142333002/diff/180001/src/asmjs/typing-asm.cc
File src/asmjs/typing-asm.cc (right):

https://codereview.chromium.org/2142333002/diff/180001/src/asmjs/typing-asm.c...
src/asmjs/typing-asm.cc:1: // Copyright 2015 the V8 project authors. All rights
reserved.
On 2016/07/14 at 22:00:47, adamk wrote:
> Did this file get accidentally added as part of some rebase?

Yup. Fixed.

https://codereview.chromium.org/2142333002/diff/180001/src/parsing/parameter-...
File src/parsing/parameter-initializer-rewriter.cc (left):

https://codereview.chromium.org/2142333002/diff/180001/src/parsing/parameter-...
src/parsing/parameter-initializer-rewriter.cc:114: else
On 2016/07/14 at 22:00:47, adamk wrote:
> Why does this else go away?

It prevents recursing into statements in DoExpressions. Those statements can
contain temporaries (and did, in previous versions of this code), but this
'else' prevents the Rewriter from being able to see and re-scope them. This
caused crashes. (As far as I can tell, this code path could only have been hit
by DoExpressions anyway, since this Rewriter is called on an Expression and does
not recurse into function bodies.)

[bakkot, 2016-07-15 00:19:42]

The CQ bit was checked by bakkot@google.com to run a CQ dry run

[commit-bot: I haz the power, 2016-07-15 00:19:48]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-15 00:44:04]

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

[commit-bot: I haz the power, 2016-07-15 00:44:05]

Dry run: This issue passed the CQ dry run.

[rmcilroy, 2016-07-15 09:24:03]

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

[rmcilroy, 2016-07-15 09:24:04]

> Adding bmeurer as a reviewer (and CC mstarzinger) for compiler thoughts on
this;
> he'd indicated interest in desugaring classes some time ago (will be needed
for
> OWNERS as well).

> My high level thoughts is that while this deletes a lot of code, it also
removes
> the ability for the optimizing compilers to do much: all the interesting logic
> happens in the runtime function. So I'm interested to see what Benedikt's take
> on that is.

Drive-by comment - if our end-goal is to have the parser only feed ignition, and
use bytecode for all other compiler front-ends, then this might not save too
much code at the end of the day. Not sure if this impacts the short-term
decision here though.

[dehrenberg1, 2016-07-18 16:49:05]

On 2016/07/15 09:24:04, rmcilroy wrote:
> > Adding bmeurer as a reviewer (and CC mstarzinger) for compiler thoughts on
> this;
> > he'd indicated interest in desugaring classes some time ago (will be needed
> for
> > OWNERS as well).
> 
> > My high level thoughts is that while this deletes a lot of code, it also
> removes
> > the ability for the optimizing compilers to do much: all the interesting
logic
> > happens in the runtime function. So I'm interested to see what Benedikt's
take
> > on that is.
> 
> Drive-by comment - if our end-goal is to have the parser only feed ignition,
and
> use bytecode for all other compiler front-ends, then this might not save too
> much code at the end of the day. Not sure if this impacts the short-term
> decision here though.

Part of the goal is to move class definition logic into the parser to assist the
implementation of other class features, such as property declarations. However,
looking at it more closely, I think class  property declarations should to some
extent touch different code (constructors and super) than what this patch ends
up touching. Still, I think it's a benefit to code health to make a change like
this, as we're not ready to remove those other backends yet (and have been
hoping to remove them for a while already).

Aside from whether a change like this is justified at all, to be a bit more
concrete to Adam's point: I think many of us were picturing that this would
desugar into a function literal and a couple object literals. However, there is
currently no way to make an object literal with non-enumerable properties. So
one alternative would be to first give object literals that capability, then
desugar into a less imperative/runtime function-based form. I don't know how to
weigh these choices exactly; I don't think this patch will result in a
noticeable performance change, and we could always go and use the other, more
advanced desugaring strategy with non-enumerable object literals later. The
short-term benefit is that we can evolve classes more easily with their
implementation being more contained, and that there's less code to maintain when
other things in the system change.

[Benedikt Meurer, 2016-07-19 04:04:26]

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

[Benedikt Meurer, 2016-07-19 04:04:28]

+marja for parser changes.

First round of comments.

https://codereview.chromium.org/2142333002/diff/220001/src/parsing/parser.cc
File src/parsing/parser.cc (right):

https://codereview.chromium.org/2142333002/diff/220001/src/parsing/parser.cc#...
src/parsing/parser.cc:5080: property_key =
factory()->NewCallRuntime(Runtime::kToName, to_name_args,
Nit: Please add a TODO here, that we look into this %ToName again, once
performance becomes an issue.

https://codereview.chromium.org/2142333002/diff/220001/src/parsing/parser.cc#...
src/parsing/parser.cc:5136: // Call DefineClass. It takes seven arguments:
I remember when we discussed this, we wanted to actually remove the need for
%DefineClass. I.e. use the existing primitives to create the prototype.

Is it considered beneficial to use %DefineClass instead of using stores for this
purpose?

https://codereview.chromium.org/2142333002/diff/220001/src/parsing/parser.cc#...
src/parsing/parser.cc:5156: define_class_args->Add(
Why do we wrap these into JSArrays? That seems rather wasteful. Since all of
this is internal, can't we just pass the FixedArrays directly instead?

[Dan Ehrenberg, 2016-07-19 04:52:33]

First round of responses, based previous on discussions with Kevin, to save a
day round trip for review. Kevin, please correct me if I'm wrong on any of this.

https://codereview.chromium.org/2142333002/diff/220001/src/parsing/parser.cc
File src/parsing/parser.cc (right):

https://codereview.chromium.org/2142333002/diff/220001/src/parsing/parser.cc#...
src/parsing/parser.cc:5136: // Call DefineClass. It takes seven arguments:
On 2016/07/19 at 04:04:27, Benedikt Meurer wrote:
> I remember when we discussed this, we wanted to actually remove the need for
%DefineClass. I.e. use the existing primitives to create the prototype.
> 
> Is it considered beneficial to use %DefineClass instead of using stores for
this purpose?

The issue here is that the properties that are created for methods need to be
non-enumerable. Is there a way to do that in the AST currently? Seems like the
main task would be to create an object literal or store AST node which creates
non-enumerable properties, and implement it in backends.

https://codereview.chromium.org/2142333002/diff/220001/src/parsing/parser.cc#...
src/parsing/parser.cc:5156: define_class_args->Add(
On 2016/07/19 at 04:04:27, Benedikt Meurer wrote:
> Why do we wrap these into JSArrays? That seems rather wasteful. Since all of
this is internal, can't we just pass the FixedArrays directly instead?

Is there a way to create FixedArrays from the parser? I think you currently have
to be at a lower level beyond this stage to do that sort of thing, rather than
an AST node.

[marja, 2016-07-19 09:54:34]

https://codereview.chromium.org/2142333002/diff/220001/src/ast/ast.cc
File src/ast/ast.cc (right):

https://codereview.chromium.org/2142333002/diff/220001/src/ast/ast.cc#newcode285
src/ast/ast.cc:285: represented_function_->raw_name()->length() == 0;
This second part looks hacky; why is it needed? When do we have a
represented_function_ but its name length is 0? Can we not have a
represented_function_ at all in that case? Or somehow otherwise make this look
less hacky.

https://codereview.chromium.org/2142333002/diff/220001/src/parsing/parser.cc
File src/parsing/parser.cc (right):

https://codereview.chromium.org/2142333002/diff/220001/src/parsing/parser.cc#...
src/parsing/parser.cc:5156: define_class_args->Add(
On 2016/07/19 04:52:33, Dan Ehrenberg wrote:
> On 2016/07/19 at 04:04:27, Benedikt Meurer wrote:
> > Why do we wrap these into JSArrays? That seems rather wasteful. Since all of
> this is internal, can't we just pass the FixedArrays directly instead?
> 
> Is there a way to create FixedArrays from the parser? I think you currently
have
> to be at a lower level beyond this stage to do that sort of thing, rather than
> an AST node.

FixedArray is a heap object, so no. This will be called on a background thread,
so we can't interact with the V8 heap.

[bakkot, 2016-07-21 23:05:33]

It sounds like this may not be worth doing, given forthcoming changes to the
compilation pipeline. I'll make a smaller change that just puts class literals
in their own block scope within a DoExpression (so that all block scopes are
attached to blocks).

[bakkot, 2016-07-22 19:55:45]

On 2016/07/21 at 23:05:33, bakkot wrote:
> It sounds like this may not be worth doing, given forthcoming changes to the
compilation pipeline. I'll make a smaller change that just puts class literals
in their own block scope within a DoExpression (so that all block scopes are
attached to blocks).

Said change is at https://codereview.chromium.org/2176653003.