Open gibson042 opened 3 weeks ago
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.
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.
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
Actual behavior
Expected behavior
In statement position with an
Await
parameter (e.g., inside anasync
function),await null ?? notAwaited;
should parse as:;
??
BitwiseORExpression[?In, ?Yield, ?Await]await
UnaryExpression[?Yield, +Await]null
test262 pull request: https://github.com/tc39/test262/pull/4204