The `compareArray` utility function returns a boolean value describing
whether or not the input arrays are equivalent--it does not throw an
exception when invoked with non-equivalent arrays. Prior to this commit,
however, two tests invoked `compareArray` without inspecting its return
value, so it had no impact on the result of the test.
Update the tests to fail when the "expected" and "actual" arrays are not
equivalent.
This reverts commit b690cb67be, reversing
changes made to 50dd431dff. This is
necessary because the reverted changeset reduced coverage by an unknown
extent.
These tests were designed to test the built-in "Promise.race Resolve
Element function," but ECMA262 does not describe such a function.
Contrary to the test's description, the function under test is created
by the InstantiateArrowFunctionExpression abstract operation. The
following tests verify most of the details directly (only the function
object's extensibility was not already tested by the existing tests):
- test/language/expressions/arrow-function/name.js
- test/language/expressions/arrow-function/throw-new.js
- test/language/expressions/arrow-function/prototype-rules.js
The definition of the built-in resolving functions is closely related,
but Test262 already includes tests for the corresponding concerns:
- test/built-ins/Promise/resolve-function-extensible.js
- test/built-ins/Promise/resolve-function-name.js
- test/built-ins/Promise/resolve-function-nonconstructor.js
- test/built-ins/Promise/resolve-function-prototype.js
Remove the tests and introduce one additional test to preserve coverage
while improving discoverability.
For asynchronous tests, the contract between test file and test runner
is implicit: runners are expected to inspect the source code for
references to a global `$DONE` identifier.
Promote a more explicit contract between test file and test runner by
introducing a new frontmatter "tag", `async`. This brings asynchronous
test configuration in-line with other configuration mechanisms and also
provides a more natural means of test filtering.
The modifications to test files was made programatically using the
`grep` and `sed` utilities:
$ grep "\$DONE" test/ -r --files-with-match --null | \
xargs -0 sed -i 's/^\(flags:\s*\)\[/\1[async, /g'
$ grep "\$DONE" test/ -rl --null | \
xargs -0 grep -E '^flags:' --files-without-match --null | \
xargs -0 sed -i 's/^---\*\//flags: [async]\n---*\//'
Add tests that assert behavior when a Promise is resolved with another
Promise whose `then` method has been overridden. Because all objects
with a `then` method are treated equivalently, the presence of a
[[PromiseState]] internal slot should have no effect on program
behavior.
These tests guard against a faulty optimization originally implemented
in V8:
https://bugs.chromium.org/p/v8/issues/detail?id=3641
Remove files that tested both PerformPromiseThen and
PromiseResolveFunction in favor of new tests that test
PromiseResolveFunction more directly and completely.
The `negative` frontmatter tag expresses an expectation for the behavior
of the test file as a whole. The `assert.throws` helper function offers
more fine-grained control over expectations because it may be applied to
specific statements and expressions. This makes it preferable in cases
where it may be used (i.e. when the test body does not describe a syntax
error or early error).
Re-implement assertions for errors to use the `assert.throws` helper
function wherever possible.
Mike Pennisi
rwaldron
Alexey Shvayka
Marja Hölttä
Leo Balter
Gus Caplan
Adrian Heine
André Bargull
Kevin Gibbons
Gorkem Yakin
C. Scott Ananian
Brian Terlson