[Bug]: incorrectly rejects await when following a function with an arrow in default parameters

[bakkot]

💻

• Would you like to work on a fix?

How are you using Babel?

Programmatic API (babel.transform, babel.parse)

Input code

(async function () {
  function f(_=()=>null) {}
  await null;
});

or

(function* () {
  function f(_=()=>null) {}
  yield;
});

Configuration file name

package.json

Configuration

No response

Current and expected behavior

These are both valid programs but are rejected with

SyntaxError: 'await' is not allowed in async function parameters.

and

Yield expression is not allowed in formal parameters.

respectively

Environment

This is with @babel/parser: 7.15.8

Possible solution

No response

Additional context

I found this with a fuzzer, not in real code, so prioritize accordingly. That said, these do actually seem more plausible than many fuzzer-derived bugs.

[babel-bot]

Hey @bakkot! 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.

[JLHwung]

The error "'await' is not allowed in async function parameters." and "Yield expression is not allowed in formal parameters." are recorded in a ExpressionScope (packages/babel-parser/src/util/expression-scope.js) and thrown later when we are sure the arrow head () indeed starts an arrow function.

We should check if the ExpressionScope is correctly handled when we are parsing an arrow function. This can be a good first issue.

[nicolo-ribaudo]

If it is the first time that you contribute to Babel, follow these steps: (you need to have make and yarn available on your machine)

1. Write a comment there to let other possible contributors know that you are working on this bug.
2. Fork the repo
3. Run git clone https://github.com/<YOUR_USERNAME>/babel.git && cd babel
4. Run yarn && make bootstrap
5. Wait ⏳
6. Run make watch (or make build whenever you change a file)
7. Add a test (only input.js; output.json will be automatically generated)
8. Update the code!
9. yarn jest babel-parser to run the tests
   • If some test outputs don't match but the new results are correct, you can delete the bad output.js files and run the tests again
   • If you prefer, you can run OVERWRITE=true yarn jest babel-parser and they will be automatically updated.
10. If it is working, run make test to run all the tests
11. Run git push and open a PR!

[The-x-Theorist]

Hello I'd like to start working on this if possible. Any ideas on how I could get started with this issue specifically?

[JLHwung]

@The-x-Theorist If it is the first time you contribute to Babel, see Nicolò's comment above on setting up the project.

This issue is on babel parser. If you are not familiar with the topic, which is absolutely okay, you can start by trying out https://astexplorer.net/ (Select JavaScript then @babel/parser) or reading tutorials about parsing and AST.

If you already had some experience on developing a parser, you can start by

babel/packages/babel-parser/src/parser/expression.js

Line 2304 in fb7ddf4

parseArrowExpression(

and scrutinize how ExpressionScope is handled when Babel is parsing arrow expression -- because the OP's error is thrown when an ExpressionScope is validated. For the definition of Expression Scope, see here.

For more questions, you can ask team members on Slack.

[The-x-Theorist]

@JLHwung Where should a test be written in a directory?

[nicolo-ribaudo]

You can add one for await in https://github.com/babel/babel/tree/main/packages/babel-parser/test/fixtures/es2017/async-functions and one for yield in https://github.com/babel/babel/tree/main/packages/babel-parser/test/fixtures/es2015/yield

[azeez1776]

Hello, can I work on the problem?

[The-x-Theorist]

@azeez1776 I'm currently working on this give me some time please, If I won't be able to take it forward I'll let you know.

[azeez1776]

@The-x-Theorist Okay, wish you luck.

[The-x-Theorist]

@The-x-Theorist If it is the first time you contribute to Babel, see Nicolò's comment above on setting up the project.

This issue is on babel parser. If you are not familiar with the topic, which is absolutely okay, you can start by trying out https://astexplorer.net/ (Select JavaScript then @babel/parser) or reading tutorials about parsing and AST.

If you already had some experience on developing a parser, you can start by

babel/packages/babel-parser/src/parser/expression.js

Line 2304 in fb7ddf4

parseArrowExpression(

and scrutinize how ExpressionScope is handled when Babel is parsing arrow expression -- because the OP's error is thrown when an ExpressionScope is validated. For the definition of Expression Scope, see here.
For more questions, you can ask team members on Slack.

Error is recorded when await expression is parsed.
Inside parseAwait()
this.expressionScope.recordParameterInitializerError( node.start, Errors.AwaitExpressionFormalParameter, );

But how it can be avoided to not record the error for this scenario.

[JLHwung]

But how it can be avoided to not record the error for this scenario.

Good question! Note that the recorded error may not throw, it is eagerly recorded in case we need to throw later. For example,

async () => {
  async ({ [await x]: 1 }); // valid
  async ({ [await x]: 1 }) => {}; // invalid
}

Babel will create an AsyncArrowScope for async (..., we need to record the await error but we can't throw the error until we see an => after async( ... ), otherwise we just discard the recorded errors.

Now let's head back to OP's example, I will mark the expected expression scope changes in comments.

(async function 
// enter ParameterDeclarationScope
(
// exit ParameterDeclarationScope
) 
// enter ExpressionScope E1
{
  function f
// enter ParameterDeclarationScope
(
_=
// enter ArrowHeadScope
(
// exit ArrowHeadScope
)=>
// enter ExpressionScope E2
null
// exit ExpressionScope E2
// exit ParameterDeclarationScope
) 
// enter ExpressionScope E3
{
// exit ExpressionScope E3
}
  await null;
// exit ExpressionScope E1
});

Note that if it works as expected, we should never throw the error for await null because it is in the ExpressionScope (E1). I suspect the bug is related to how we parse the arrow expression, specifically we should check if the scope is entered / exited as expected.

[The-x-Theorist]

@JLHwung Thank you helping out, this will help me for solving the problem. 😄