Fix await binding error within static block

[JLHwung]

Q	A
Fixed Issues?	Implements tc39/proposal-class-static-block#46
Tests Added + Pass?	Yes
License	MIT

This PR aligns Babel behaviour to current V8 implementation, which follows Contains Static Semantics. However since this behaviour is not specified in that way, we have ongoing discussions in tc39/proposal-class-static-block#43

I will mark this PR as ready when consensus is reached.

This PR implements tc39/proposal-class-static-block#46. The spec now adds [Await] production parameter to static block and throw if it contains (specified in SDO containsAwait) AwaitExpression and for await. However implementing the SDO containsAwait requires scan of whole AST tree, which is not performant. Babel parses the StaticBlock in [~Await] and uses parser scopes to throw if an await identifier is within the static block.

See scope#inStaticBlock for current implementation detail.

[babel-bot]

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

[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 0ce8c72:

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

[KFlash]

@JLHwung Why not set 'this.scope.inStaticBlock' when you enter a static block, and unset this again every time you enter function body, arrow or block statement, and then for await check if this is set and if so, throw.

[JLHwung]

@KFlash Besides function body, arrow, we should also take care of the class field initializers. A plain block statement { expr } inherit the await production, so we should not reset for plain block. Essentially it should be maintained in whatever production that does not inherit [Await], which is easily overlooked when new language feature is introduced. A boolean state has fastest access time, however such state inStaticBlock will only be accessed when we see a binding identifier named await, which is rare.

I think the current approach is easier to maintain because we already have to push a lexical scope for static block, so an extra mark on the scope, compacted to bit arrays, does not introduce extra recording tasks. The worst scenario of current approach is an await nested in N block statements within a static block, while the boolean approach certainly performs better in this scenario.

[KFlash]

@JLHwung An easy solution for this is to "copy" what the author of this proposal did. Look at the open PR for implementation of static block in the Typescript repo.