Class fields, part 1 (parsing and infrastructure)

Class fields, part 1 (parsing and infrastructure)

This is one part of a WIP implementation of the stage-2 proposal to add
fields to classes: https://github.com/tc39/proposal-class-public-fields

See design doc:
https://docs.google.com/document/d/1WRtNm3ZLNJT1WVr8aq4RJuByYgfuAFAhj20LwTW6JVE/

This adds support for parsing fields in classes, including
infrastructure. In particular, it adds:
* Two booleans on function literal AST nodes
* Two compiler hints on SharedFunctionInfos representing said bools
* A new type of ClassLiteralProperty, FIELD
* Parser support for the syntax
* Syntax tests
* A flag to enable it.

Currently the fields are parsed and then droppped. Subsequent
patches will add semantics, mostly by desugaring in the parser and
the remainder in the non-crankshaft backends.

BUG=v8:5367
Committed: https://crrev.com/fe6b76d4911f6934359a5ca368c0a75f74110179
Cr-Commit-Position: refs/heads/master@{#39459}

[bakkot, 2016-09-06 22:53:42]

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

[commit-bot: I haz the power, 2016-09-06 22:53:49]

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

[bakkot, 2016-09-06 23:12:42]

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

[bakkot, 2016-09-06 23:12:43]

PTAL. Not all of the changes make sense without context, but the next patch will
add code
referencing them.

I think the only scary thing about this is the additional bools on
FunctionLiteral nodes.
They're used to communicate with SharedFunctionInfo to allow reparsing; I
haven't found a
good way to avoid them.

[commit-bot: I haz the power, 2016-09-06 23:25:44]

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

[commit-bot: I haz the power, 2016-09-06 23:25:45]

Dry run: This issue passed the CQ dry run.

[Dan Ehrenberg, 2016-09-06 23:55:59]

Looks mostly good, a couple comments.

https://codereview.chromium.org/2315733003/diff/1/src/ast/ast.h
File src/ast/ast.h (right):

https://codereview.chromium.org/2315733003/diff/1/src/ast/ast.h#newcode2698
src/ast/ast.h:2698: bool is_class_field_initializer_;  // TODO(bakkot) this
should be a bitfield
As we discussed offline, it'd be nice to find these bits in FunctionKind before
submitting, especially given all the ongoing work in reducing the memory that
parser structures take.

https://codereview.chromium.org/2315733003/diff/1/src/ast/ast.h#newcode2788
src/ast/ast.h:2788: VariableProxy* static_initializer_proxy_;  // TODO(bakkot)
initialize inline
What do you mean by this TODO?

https://codereview.chromium.org/2315733003/diff/1/test/cctest/test-parsing.cc
File test/cctest/test-parsing.cc (right):

https://codereview.chromium.org/2315733003/diff/1/test/cctest/test-parsing.cc...
test/cctest/test-parsing.cc:4659: "async\n a",
How about some fields called await?

https://codereview.chromium.org/2315733003/diff/1/test/cctest/test-parsing.cc...
test/cctest/test-parsing.cc:4697: "get\n a",
How about some fields called yield?

[bakkot, 2016-09-07 19:30:12]

Addressed Dan's comments. cc bmeurer@ for the AST change.

https://codereview.chromium.org/2315733003/diff/1/src/ast/ast.h
File src/ast/ast.h (right):

https://codereview.chromium.org/2315733003/diff/1/src/ast/ast.h#newcode2698
src/ast/ast.h:2698: bool is_class_field_initializer_;  // TODO(bakkot) this
should be a bitfield
On 2016/09/06 at 23:55:59, Dan Ehrenberg wrote:
> As we discussed offline, it'd be nice to find these bits in FunctionKind
before submitting, especially given all the ongoing work in reducing the memory
that parser structures take.

I ended up just expanding the bitfield in FunctionLiterals, which (after some
past reorganization of Expressions) doesn't use any more space, as far as I can
tell.

https://codereview.chromium.org/2315733003/diff/1/src/ast/ast.h#newcode2788
src/ast/ast.h:2788: VariableProxy* static_initializer_proxy_;  // TODO(bakkot)
initialize inline
On 2016/09/06 at 23:55:59, Dan Ehrenberg wrote:
> What do you mean by this TODO?

Sorry, that's stale. I was originally going to have static_initializer_proxy_ be
initialized to its final value in the constructor, but decided against it.

https://codereview.chromium.org/2315733003/diff/1/test/cctest/test-parsing.cc
File test/cctest/test-parsing.cc (right):

https://codereview.chromium.org/2315733003/diff/1/test/cctest/test-parsing.cc...
test/cctest/test-parsing.cc:4659: "async\n a",
On 2016/09/06 at 23:55:59, Dan Ehrenberg wrote:
> How about some fields called await?

Done.

https://codereview.chromium.org/2315733003/diff/1/test/cctest/test-parsing.cc...
test/cctest/test-parsing.cc:4697: "get\n a",
On 2016/09/06 at 23:55:59, Dan Ehrenberg wrote:
> How about some fields called yield?

Done. Though these are just property names, and can be any identifier (or
number, or string literal).

[Benedikt Meurer, 2016-09-08 03:51:01]

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

[Benedikt Meurer, 2016-09-08 03:51:02]

LGTM on ast with nit.

https://codereview.chromium.org/2315733003/diff/40001/src/ast/scopes.h
File src/ast/scopes.h (right):

https://codereview.chromium.org/2315733003/diff/40001/src/ast/scopes.h#newcod...
src/ast/scopes.h:682: // property to store information about the number of
fields.
That function name seems misleading then.

[bakkot, 2016-09-08 22:37:28]

Description was changed from

==========
Class fields, part 1 (parsing and infrastructure)

This is one part of a WIP implementation of the stage-2 proposal to add
fields to classes: https://github.com/tc39/proposal-class-public-fields

This adds support for parsing fields in classes, including
infrastructure. In particular, it adds:
* Two booleans on function literal AST nodes
* Two compiler hints on SharedFunctionInfos representing said bools
* A new type of ClassLiteralProperty, FIELD
* Parser support for the syntax
* Syntax tests
* A flag to enable it.

Currently the fields are parsed and then droppped. Subsequent
patches will add semantics, mostly by desugaring in the parser and
the remainder in the non-crankshaft backends.
==========

to

==========
Class fields, part 1 (parsing and infrastructure)

This is one part of a WIP implementation of the stage-2 proposal to add
fields to classes: https://github.com/tc39/proposal-class-public-fields

This adds support for parsing fields in classes, including
infrastructure. In particular, it adds:
* Two booleans on function literal AST nodes
* Two compiler hints on SharedFunctionInfos representing said bools
* A new type of ClassLiteralProperty, FIELD
* Parser support for the syntax
* Syntax tests
* A flag to enable it.

Currently the fields are parsed and then droppped. Subsequent
patches will add semantics, mostly by desugaring in the parser and
the remainder in the non-crankshaft backends.

BUG=v8:5367
==========

[Dan Ehrenberg, 2016-09-09 20:58:15]

lgtm

Looks good, just a nit remaining.

https://codereview.chromium.org/2315733003/diff/40001/src/parsing/parser-base.h
File src/parsing/parser-base.h (right):

https://codereview.chromium.org/2315733003/diff/40001/src/parsing/parser-base...
src/parsing/parser-base.h:2163:
scope()->SetLanguageMode(static_cast<LanguageMode>(language_mode() | STRICT));
Nit: Now that we don't have strong mode, I think this can just be STRICT, no
need to take the current language mode into account.

[bakkot, 2016-09-09 22:35:03]

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

[commit-bot: I haz the power, 2016-09-09 22:35:05]

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-09-09 23:09:20]

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

[commit-bot: I haz the power, 2016-09-09 23:09:21]

Dry run: This issue passed the CQ dry run.

[Dan Ehrenberg, 2016-09-13 18:00:52]

lgtm

[bakkot, 2016-09-13 18:05:03]

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

[commit-bot: I haz the power, 2016-09-13 18:05:14]

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-09-13 18:53:45]

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

[commit-bot: I haz the power, 2016-09-13 18:53:46]

Dry run: Try jobs failed on following builders:
  v8_linux_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_rel_ng/builds/12610)
  v8_linux_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_rel_ng_triggered/b...)

[bakkot, 2016-09-15 21:16:32]

Description was changed from

==========
Class fields, part 1 (parsing and infrastructure)

This is one part of a WIP implementation of the stage-2 proposal to add
fields to classes: https://github.com/tc39/proposal-class-public-fields

This adds support for parsing fields in classes, including
infrastructure. In particular, it adds:
* Two booleans on function literal AST nodes
* Two compiler hints on SharedFunctionInfos representing said bools
* A new type of ClassLiteralProperty, FIELD
* Parser support for the syntax
* Syntax tests
* A flag to enable it.

Currently the fields are parsed and then droppped. Subsequent
patches will add semantics, mostly by desugaring in the parser and
the remainder in the non-crankshaft backends.

BUG=v8:5367
==========

to

==========
Class fields, part 1 (parsing and infrastructure)

This is one part of a WIP implementation of the stage-2 proposal to add
fields to classes: https://github.com/tc39/proposal-class-public-fields

See design doc:
https://docs.google.com/document/d/1WRtNm3ZLNJT1WVr8aq4RJuByYgfuAFAhj20LwTW6JVE/

This adds support for parsing fields in classes, including
infrastructure. In particular, it adds:
* Two booleans on function literal AST nodes
* Two compiler hints on SharedFunctionInfos representing said bools
* A new type of ClassLiteralProperty, FIELD
* Parser support for the syntax
* Syntax tests
* A flag to enable it.

Currently the fields are parsed and then droppped. Subsequent
patches will add semantics, mostly by desugaring in the parser and
the remainder in the non-crankshaft backends.

BUG=v8:5367
==========

[bakkot, 2016-09-15 21:16:41]

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

[commit-bot: I haz the power, 2016-09-15 21:16:45]

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-09-15 21:52:56]

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

[commit-bot: I haz the power, 2016-09-15 21:52:57]

Dry run: This issue passed the CQ dry run.

[bakkot, 2016-09-16 00:39:43]

The CQ bit was checked by bakkot@google.com

[bakkot, 2016-09-16 00:39:43]

The patchset sent to the CQ was uploaded after l-g-t-m from bmeurer@chromium.org
Link to the patchset: https://codereview.chromium.org/2315733003/#ps100001
(title: "whitespace")

[commit-bot: I haz the power, 2016-09-16 00:39:49]

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-09-16 00:42:37]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2016-09-16 00:42:58]

Description was changed from

==========
Class fields, part 1 (parsing and infrastructure)

This is one part of a WIP implementation of the stage-2 proposal to add
fields to classes: https://github.com/tc39/proposal-class-public-fields

See design doc:
https://docs.google.com/document/d/1WRtNm3ZLNJT1WVr8aq4RJuByYgfuAFAhj20LwTW6JVE/

This adds support for parsing fields in classes, including
infrastructure. In particular, it adds:
* Two booleans on function literal AST nodes
* Two compiler hints on SharedFunctionInfos representing said bools
* A new type of ClassLiteralProperty, FIELD
* Parser support for the syntax
* Syntax tests
* A flag to enable it.

Currently the fields are parsed and then droppped. Subsequent
patches will add semantics, mostly by desugaring in the parser and
the remainder in the non-crankshaft backends.

BUG=v8:5367
==========

to

==========
Class fields, part 1 (parsing and infrastructure)

This is one part of a WIP implementation of the stage-2 proposal to add
fields to classes: https://github.com/tc39/proposal-class-public-fields

See design doc:
https://docs.google.com/document/d/1WRtNm3ZLNJT1WVr8aq4RJuByYgfuAFAhj20LwTW6JVE/

This adds support for parsing fields in classes, including
infrastructure. In particular, it adds:
* Two booleans on function literal AST nodes
* Two compiler hints on SharedFunctionInfos representing said bools
* A new type of ClassLiteralProperty, FIELD
* Parser support for the syntax
* Syntax tests
* A flag to enable it.

Currently the fields are parsed and then droppped. Subsequent
patches will add semantics, mostly by desugaring in the parser and
the remainder in the non-crankshaft backends.

BUG=v8:5367

Committed: https://crrev.com/fe6b76d4911f6934359a5ca368c0a75f74110179
Cr-Commit-Position: refs/heads/master@{#39459}
==========

[commit-bot: I haz the power, 2016-09-16 00:42:59]

Patchset 6 (id:??) landed as
https://crrev.com/fe6b76d4911f6934359a5ca368c0a75f74110179
Cr-Commit-Position: refs/heads/master@{#39459}