Some await expressions break XS parsing

[gibson042]

Environment: XS 15.5.1, slot 32 bytes, ID 4 bytes

Description
XS fails to parse a ConditionalExpression that starts with an await.

Steps to Reproduce

async function fn() {
  const notAwaited = {
    then() { throw Error("unexpected `then` invocation"); },
  };
  await null ?? notAwaited; // but at least `||` and `&&` are also affected
}
print("START");
fn().then(() => print("END"));

Actual behavior

SyntaxError: missing ;

Expected behavior

START
END

In statement position with an _Await parameter (e.g., inside an async function), await null ?? notAwaited; should parse as:

• ExpressionStatement_{[Yield, Await]} → Expression_{[+In, ?Yield, ?Await]} ;
• Expression_{[In, Yield, Await]} → AssignmentExpression_{[?In, ?Yield, ?Await]}
• AssignmentExpression_{[In, Yield, Await]} → ConditionalExpression_{[?In, ?Yield, ?Await]}
• ConditionalExpression_{[In, Yield, Await]} → ShortCircuitExpression_{[?In, ?Yield, ?Await]}
• ShortCircuitExpression_{[In, Yield, Await]} → CoalesceExpression_{[?In, ?Yield, ?Await]}
• CoalesceExpression_{[In, Yield, Await]} → CoalesceExpressionHead_{[?In, ?Yield, ?Await]} ?? BitwiseORExpression_{[?In, ?Yield, ?Await]}
  • CoalesceExpressionHead_{[In, Yield, Await]} → … → UnaryExpression_{[Yield, Await]}
    • UnaryExpression_{[Yield, Await]} → _[+Await] AwaitExpression_[?Yield]
    • AwaitExpression_[Yield] → await UnaryExpression_{[?Yield, +Await]}
    • UnaryExpression_{[Yield, Await]} → UpdateExpression_{[Yield, Await]} → … → PrimaryExpression_{[Yield, Await]} → Literal → NullLiteral → null
  • BitwiseORExpression_{[In, Yield, Await]} → … → PrimaryExpression_{[Yield, Await]} → IdentifierReference_{[Yield, Await]} → Identifier _{but not ReservedWord}

test262 pull request: tc39/test262#4204

[phoddie]

Thanks for reporting this.

The issue is real but more obscure than it seems at first. The problem only happens if the (Stage 3) explicit resource management API support is enabled in the XS build with mxExplicitResourceManagement. That is only the case in xst -- which is, of course, what you are using in your tests here. The Moddable SDK today defaults to explicit resource management being off.

The problem is caused by using not being a keyword and the lookahead required in the parser to handle that. Obviously we need to correct this, but it may take a bit as it is a little tricky.

[phoddie]

Quick update – we are testing a fix for this. It requires some non-trivial changes to the parser for the additional look-ahead, so we are testing it internally for a bit before pushing it public.

[phoddie]

Fixed.