* AsyncFunction: Add tests ensuring the new 1-tick await behaviour
This commit adds 3 tests ensuring the optimized behaviour of await
(see https://github.com/tc39/ecma262/pull/1250) in the following cases:
- async functions
- yielding from async generator functions
- for-await-of loops
* AsyncFunction: Add tests ensuring the monkey-patched promises behaviour
This commit adds 2 more tests ensuring the optimized behaviour of await
(see tc39/ecma262#1250) in the following cases:
- awaiting on a native promise with monkey-patched "then"
- awaiting on a non-native promise (a "thenable" object)
* AsyncFunction: Add tests ensuring the non-native promises behaviour
This commit adds 1 more tests ensuring the optimized behaviour of await
(see tc39/ecma262#1250) in the following cases:
- awaiting on a non-promise, non-thenable object
It also renames the previous test for non-promise (a "thenable" object)
to distinguish from the new case.
The commit adds checks for proper await/promises interleaving in the
aforementioned cases and includes a small code clean-up.
* AsyncFunction: Refactor tests ensuring the new 1-tick await behaviour
Gather all the tests to their appropriate folder and update copyright header.
The tests for the parsing of compound assignment expressions were
expressed using eval. This made the tests more complex than necessary
and also prevented the tests from providing value to ECMAScript parsers.
Remove the use of eval and instead express the expectations with
literal source text.
- Add cases for mixing module and script code
- Rename test case from return promise to thenable
- Fix script code case with valid loaded fixture
- Add a test to assert a promise return
- Add case for specifier toString rejection
- Add case for specifier toString
- Test Assignment expression abrupt completion
- Test Promise return
This behavior is covered by another test in this directory:
`arguments-strict-single.js`. Although the syntax error happens to occur
within the body of a function expression, this distinction is not
significant enough to warrant the test's presence nor does it motivate
the introduction of many similar negative syntax tests which are
currently unavailable.
The tests for the parsing of variable declarations were expressed using
eval. This made the tests more complex than necessary and also prevented
the tests from providing value to ECMAScript parsers.
Remove the use of eval and instead express the expectations with literal
source text.
The tests for the parsing of `for/in` loops were expressed using eval.
This made the tests more complex than necessary and also prevented the
tests from providing value to ECMAScript parsers.
Remove the use of eval and instead express the expectations with literal
source text. Move the tests to the `for-in` directory to better reflect
the grammar production that they test.
Two tests placed within the "variable" directory do not include a variable
declaration. Because the behavior they assert is covered by an existing
test (test/language/arguments-object/10.5-1gs.js), they may be removed
without reducing coverage.
