refactor: raise AwaitNotInAsyncContext when an AwaitExpression will be parsed

[JLHwung]

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

When errorRecovery is enabled, Babel throws confusing AwaitNotInAsyncContext error 'await' is only allowed within async functions for function await () {}, (astexplorer) However await here is parsed as a binding identifier, there is no AwaitExpression in the AST.

Based on #12520, we can throw AwaitNotInAsyncContext only before we are sure that the expression could be interpreted as an AwaitExpression. Therefore we can simply throw unexpected reserved word in checkReservedWord when we see await in [~Await] productions and script type is module, and then overwrite the thrown errors with AwaitNotInAsyncContext after we have more contextual information. In this case the await turns out to be a part of AwaitExpression because we know there is a following UpdateExpression.

However we can only achieve this on error recovery mode, in which, essentially, all errors are delayed until the AST is completely parsed. We could consider enable errorRecovery by default in Babel 8 because of better errors.

[babel-bot]

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

[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 afbcc32:

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

[nicolo-ribaudo]

Without errorRecovery: true, Babel will still throw the first "wrong" error.
Since the error is similar I wouldn't worry too much about it, but we should add a big warning in raiseOverwrite's JSDoc description.

[JLHwung]

Yeah that's the why I mentioned "we can only achieve this on error recovery mode", although we could do a try catch and recasting the errors.

Alternatively, we can parse internally with errorRecovery: true but only throw the first one in errors if errorRecovery is false.