Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

await should be allowed when it is not in AsyncArrowHead #10988

JLHwung opened this issue Jan 11, 2020 · 3 comments

await should be allowed when it is not in AsyncArrowHead #10988

JLHwung opened this issue Jan 11, 2020 · 3 comments


Copy link

@JLHwung JLHwung commented Jan 11, 2020

Bug Report

  • I would like to work on a fix!

Current Behavior
A clear and concise description of the behavior.
The following snippet will throw SyntaxError: Await cannot be used as name inside an async function (1:1)

Input Code

  • REPL or Repo link if applicable: REPL
(await) => {}

Expected behavior/code
It should not throw because it is not in async arrow parameters, which means await is a plain identifier and should be allowed in ArrowParameters because it does not have [Await] production parameter.

Babel Configuration
REPL, no plugins are enabled



Possible Solution

Should revisit how awaitPos is tracked in the parser. You can pay attention to

this.state.awaitPos === -1 &&
(this.state.maybeInArrowParameters || this.isAwaitAllowed())
) {
this.state.awaitPos = this.state.start;

where awaitPos is updated when it may be in arrow parameters. It was used to track awaitPos on cases like

async ( x = (await) => {}) => {}

however it becomes overkill when it is not in async arrow parameters. Consider add a new parser state maybeInAsyncArrowHead when parsing ambiguous async arrow

It should be similar to maybeAsyncArrow but it should have longer lifecycle -- maybeInAsyncArrowHead should be true during the whole async arrow parameters. i.e.

// top level
async ( // maybeInAsyncArrowHead : true
  x = ( // maybeInAsyncArrowHead : true
    await // register the `awaitPos`
  ) => async ( // oldMaybeInAsyncArrowHead should be saved, new maybeInAsyncArrowHead should be true
  ) => {}
); // we does not see an arrow, so the parsed ambiguous async arrow is indeed a CallExpression, reset `awaitPos`.

When we are sure we are not parsing an async arrow, i.e. async(foo), we should reset awaitPos if state.maybeInAsyncArrowHead is false.

Then we can replace maybeInArrowParameters by maybeInAsyncArrowHead it should not record awaitPos for (await) => {}.


This comment has been minimized.

Copy link

@babel-bot babel-bot commented Jan 11, 2020

Hey @JLHwung! We really appreciate you taking the time to report an issue. The collaborators on this project attempt to help as many people as possible, but we're a limited number of volunteers, so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack community that typically always has someone willing to help. You can sign-up here for an invite."


This comment has been minimized.

Copy link

@arku arku commented Jan 14, 2020

@JLHwung I would like to fix this bug 🙂


This comment has been minimized.

Copy link

@rajasekarm rajasekarm commented Jan 14, 2020

@arku Go ahead. It's yours now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
4 participants
You can’t perform that action at this time.