Thanks for the report, and the link to the acorn issue.  This looks worth considering, based on the community interest.  kozy@, could you please examine?

Thanks kozy!

There's the beginnings of a plugin here:
https://github.com/victor-homyakov/acorn-object-rest-spread

also an old one here:
https://github.com/UXtemple/acorn-object-spread

and Babel's flavor here:
https://github.com/babel/babel/blob/master/packages/babel-plugin-transform-object-rest-spread/src/index.js

We'll use plugin or roll acorn as soon as object spread operator is supported. We're looking for hero who will help community with it and sadly have too much other issues to work on now.

Hi Kozy,

I ended up adding my own based on Victor Homyakov's:
https://github.com/standard-things/esm/blob/master/src/acorn-ext/object-rest-spread.js

It's loose to enable parsing, no need to be super strict for it since I'm not doing anything with the object rest/spread stuff. I think that approach would work for the dev tools too since v8 will handle syntax specifics when executing the code.

 Issue 784772  has been merged into this issue.

This comment makes acorn a non starter:
https://github.com/ternjs/acorn/issues/388#issuecomment-321909465

If there's always going to be a mismatch between V8 and acorn then that's going to lead to more of these bugs, especially given how aggressive V8 is when it comes to implementing stage3 features.

We should revisit the usage of acorn if they're not going to support stage3 features.

> We should revisit the usage of acorn if they're not going to support stage3 features.

Or help contribute quality plugins to the Acorn ecosystem.

We have some ideas that we should expose ast tree in our protocol since using any kind of external libraries looks redundant when we have V8 on one protocol call distance.

I don't think this should be blocked on exposing the AST via protocol. It's not practical to expose the raw AST as it changes frequently and includes desugarings that imo should not be exposed to the user. so that requires some good design.

I also don't think that protocol extension should be a two way channel where you can feed a modified AST back to V8 to compile.

I think the best solution is to just offer a way to have V8's parser accept what's expect for REPL input.

FWIW I'm not convinced by this use case that we should have yet another parsing mode (.. apart from sloppy, strict and module). Especially if the fix here is to just use a drop-in replacement for acorn.

I agree that AST requires good design. We need it for other features as well and based on all use cases we can figure out the best format.
We do not need a two way channel in protocol, code generation looks like much simpler problem as code parsing and user can just evaluate generated source.

REPL mode sounds good to me since it allow DevTools and Node.js have top-level await support without maintaining tricky transform logic based on external library. But from another point I started work on support for top-level-await from trying to implement it inside V8 and it does not look easy.

I do think that introducing a new parsing mode for this makes sense, given that both Node.js and DevTools have a need for this functionality.

AST tranformation based on a parser other than the one V8 ships with will always have issues of compatibility with V8, is added complexity, and can never be as performant as V8's parser.

I also don't see it as a parsing mode next to sloppy, strict and module as its not a language mode, but rather a flag that for example allows top-level await and performs additional desugarings to make it possible.

The discussion here focuses on parsing, but there's more to top-level await than parsing. What code would V8 generate when it encounters a top-level await? The current code generation depends on the await being inside an async function, but we don't want to treat all REPL code as an async function (e.g., "return" should not be allowed).

Not sure if this should be discussed here or on the attached V8 issue.

FYI Node landed Acorn use to add top-level await support to its REPL:
https://github.com/nodejs/node/pull/15566

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7c4c36f75aad4664d18681be4be7cee91a44676d

commit 7c4c36f75aad4664d18681be4be7cee91a44676d
Author: Alexey Kozyatinskiy <kozyatinskiy@chromium.org>
Date: Fri Mar 09 05:01:17 2018

[DevTools] roll acorn to 5.5.3

New version of acorn support spread and rest operators.

R=dgozman@chromium.org

Bug:  chromium:756006 
Change-Id: I8c0a5a6d0f39027920f7d0e8b8df42a711262d97
Reviewed-on: https://chromium-review.googlesource.com/956559
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#542031}
[modify] https://crrev.com/7c4c36f75aad4664d18681be4be7cee91a44676d/third_party/WebKit/LayoutTests/http/tests/devtools/console/console-top-level-await-expected.txt
[modify] https://crrev.com/7c4c36f75aad4664d18681be4be7cee91a44676d/third_party/WebKit/LayoutTests/http/tests/devtools/console/console-top-level-await.js
[modify] https://crrev.com/7c4c36f75aad4664d18681be4be7cee91a44676d/third_party/WebKit/Source/devtools/front_end/formatter_worker/FormatterWorker.js
[add] https://crrev.com/7c4c36f75aad4664d18681be4be7cee91a44676d/third_party/WebKit/Source/devtools/front_end/formatter_worker/acorn/AUTHORS
[modify] https://crrev.com/7c4c36f75aad4664d18681be4be7cee91a44676d/third_party/WebKit/Source/devtools/front_end/formatter_worker/acorn/LICENSE
[modify] https://crrev.com/7c4c36f75aad4664d18681be4be7cee91a44676d/third_party/WebKit/Source/devtools/front_end/formatter_worker/acorn/acorn.js