Async Function Definitions: FormalParameters [?Await], contradicts with text

[marjakh]

Link:
14.6 Async Function Definitions

In the AsyncFunctionDeclaration production, FormalParameters are parameterized with [~Yield, ?Await]: yield is allowed as an identifier and await is allowed as an identifier iff the parent production allows it (i.e., if the async function occurs at top level, await would be allowed as an identifier).

Note 1 says:

"When Script is the syntactic goal symbol, await may be parsed as an identifier when the [Await] parameter is absent. This includes the following contexts:

• Anywhere outside of an AsyncFunctionBody or FormalParameters of an AsyncFunctionDeclaration or AsyncFunctionExpression.
• ..."

which contradicts with the productions.

The production probably should have FormalParameters parameterized with [~Yield, +Await].

In the AsyncFunctionExpression production, FormalParameters are parameterized with [~Yield, +Await] as expected.

[littledan]

The change seems to reflect the behavior of V8, ChakraCore, SpiderMonkey and JSC:

$ eshost -e "async function(await) {}"
#### jsc
SyntaxError: Can't use 'await' as a parameter name in an async function.

#### chakracore
SyntaxError: The use of a keyword for an identifier is invalid

#### spidermonkey
SyntaxError: missing formal parameter:

#### d8
SyntaxError: Unexpected reserved word

Should we give similar treatment to CoverCallExpressionAndAsyncArrowHead? It looks like that also takes Await as a parameter, but similarly, four implementations seem to consistently reject Await.

Since this is such consistent consensus among implementations, and the await parameter would be unusable if it were definable, and the patch also matches the grammar for single-parameter arrow functions (which ban async await => { /* ... */ } , I think we should definitely merge this patch.

[littledan]

The change seems to reflect the behavior of V8, ChakraCore, SpiderMonkey and JSC:

$ eshost -e "async function(await) {}"
#### jsc
SyntaxError: Can't use 'await' as a parameter name in an async function.

#### chakracore
SyntaxError: The use of a keyword for an identifier is invalid

#### spidermonkey
SyntaxError: missing formal parameter:

#### d8
SyntaxError: Unexpected reserved word

Should we give similar treatment to CoverCallExpressionAndAsyncArrowHead? It looks like that also takes Await as a parameter, but similarly, four implementations seem to consistently reject Await.

Since this is such consistent consensus among implementations, and the await parameter would be unusable if it were definable, and the patch also matches the grammar for single-parameter arrow functions (which ban async await => { /* ... */ } , I think we should definitely merge this patch.

[marjakh]

I don't think we should change this production:

CoverCallExpressionAndAsyncArrowHead[Yield, Await] :
MemberExpression[?Yield, ?Await] Arguments[?Yield, ?Await]

because we want to allow await in the "not async arrow func" case.

The "Supplemental Syntax" below CoverCallExpressionAndAsyncArrowHead already says:

"When processing an instance of the production AsyncArrowFunction: CoverCallExpressionAndAsyncArrowHead [no LineTerminator here] => AsyncConciseBody the interpretation of CoverCallExpressionAndAsyncArrowHead is refined using the following grammar:

AsyncArrowHead :
async [no LineTerminator here] ArrowFormalParameters [~Yield, +Await]"

and that already forbids await there.

So I don't think anything related to CoverCallExpressionAndAsyncArrowHead needs to be changed.

[marjakh]

I don't think we should change this production:

CoverCallExpressionAndAsyncArrowHead[Yield, Await] :
MemberExpression[?Yield, ?Await] Arguments[?Yield, ?Await]

because we want to allow await in the "not async arrow func" case.

The "Supplemental Syntax" below CoverCallExpressionAndAsyncArrowHead already says:

"When processing an instance of the production AsyncArrowFunction: CoverCallExpressionAndAsyncArrowHead [no LineTerminator here] => AsyncConciseBody the interpretation of CoverCallExpressionAndAsyncArrowHead is refined using the following grammar:

AsyncArrowHead :
async [no LineTerminator here] ArrowFormalParameters [~Yield, +Await]"

and that already forbids await there.

So I don't think anything related to CoverCallExpressionAndAsyncArrowHead needs to be changed.

[littledan]

Oh I see, good.

[littledan]

Oh I see, good.