The harness file `Test262Error.js` has not contained executable code since it
was introduced in this project [1]. The definition of the `Test262Error`
function has consistently been located in the `sta.js` harness file which test
runners are expected to inject into the test environment.
Remove the file and all references to it.
[1] See commit c33bf0e0439e6f6bf084c1524d7df8d2b41c515d
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---*\//'
Assert that the `constructor` property of the "this" value of
`Promise.prototype.then` is accessed exactly once. This guards against
implementations where repeated access is used instead of reference
passing (possibly motivated by convenience).
Repeated access of this kind was demonstrated by V8's implementation of
the specification:
https://bugs.chromium.org/p/v8/issues/detail?id=4539
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
The "mainline" tests in Test262 are converging on a more formal
structure. Files are organized as tests for either either "language"
(e.g. syntax-driven) or "built-in" (e.g. API-driven). "Language" test
locations are themselves structured according to whether the syntactic
form under test is an Expression or a Statement.
To limit ambiguity when locating/adding tests, re-organize the tests for
Annex B extensions to match this structure.
Test262 defines tests for expression-producing syntactic forms within
the `language/expressions/` directory. Most tests for object literals
conform to this structure, but 12 such tests were added to the
`language/object-literal/` directory. Move these tests to the canonical
location for object literals.
ECMAScript 2015 introduced tail call optimization for function calls
occuring in a number of positions in the grammar. Assert expected
behavior by triggering a large (but configurable) number of recursive
function calls in these positions. Compliant runtimes will execute such
programs without error; non-compliant runtimes are expected to fail
these tests by throwing an error or crashing when system resources are
exhausted.
The ES2016 draft further refines the completion values for `if` and
`with` statements. Two tests must be removed outright because the
completion value in those cases is no longer accessible from the
runtime.
In order to facilitate proper tail calls, ES2015 modified the completion
value of a number of statements.
These tests use `eval` to verify the new values.
Replace a ES2015 test where calling the TypedArray constructor with
a floating number triggered a RangeError. Within the ES2016 specs,
the same call will trigger a TypeError, as the result for
`SameValue(NewTarget, here)` will be checked before.
Remove files that tested both PerformPromiseThen and
PromiseResolveFunction in favor of new tests that test
PromiseResolveFunction more directly and completely.
Although the `for..in` statement allows Expressions to define the
iterator, only an AssignmentExpression may occupy this position in the
`for..of` statement.
