Prevent ForOfStatement from printing the forbidden sequence "for ( async of"

[Zalathar]

Q	A
Fixed Issues?	Fixes #13207
Patch: Bug Fix?	Yes
Major: Breaking Change?	No
Minor: New Feature?	No
Tests Added + Pass?	Yes
Documentation PR Link
Any Dependency Changes?	No
License	MIT

If we detect that a ForOfStatement's left-hand-side is an identifier named async, print extra parentheses around the identifier to avoid this edge-case in the ECMAScript grammar.

[babel-bot]

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/45581/

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 6faed7b:

Sandbox	Source
babel-repl-custom-plugin	Configuration
babel-plugin-multi-config	Configuration

[Zalathar]

After writing this I remembered that there's a whole subsystem dedicated to “does this node need parentheses in light of its parent”. Not sure if it makes more sense to to use that instead, or to stick with this ad-hoc code.

[Zalathar]

The alternative would be something like this in parentheses.ts:

export function Identifier(node: t.Identifier, parent: t.Node): boolean {
  return (
    node.name === "async" && t.isForOfStatement(parent) && node === parent.left
  );
}

[existentialism]

The alternative would be something like this in parentheses.ts:

export function Identifier(node: t.Identifier, parent: t.Node): boolean {
  return (
    node.name === "async" && t.isForOfStatement(parent) && node === parent.left
  );
}

👍 from me

[JLHwung]

@existentialism Oops I mentally think of your 👍 as ✅.

[existentialism]

All good, looks great thanks @Zalathar!

[thorn0]

Looks like this PR doesn't take into account that in for await (async of []); the parens are not needed.

[Zalathar]

Looks like this PR doesn't take into account that in for await (async of []); the parens are not needed.

Ah, nice catch.

Thankfully the output still happens to be correct, so it's not a disaster, but this was an oversight and at least deserves explicit tests and comments.

That said, some quick testing reveals that Babel itself doesn't know how to parse for await (async of []);, which is more concerning. So the extra parens turn out to be an unintended mitigation for an edge-case parser bug, as well as a hand-hold for any unfortunate humans who have to read this weird code.

(TODO: File and fix the parser bug!)

So once the parser bug is fixed, I'm inclined to leave the unnecessary parens as-is, or maybe remove them in compact mode only.