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 c33bf0e043
When executing multiple tests in parallel, each "child" thread would
write to the process's standard output buffer immediately upon test
completion. Because thread execution order and instruction interleaving
is non-deterministic, this made it possible for characters to be emitted
out-of-order.
When extended to support multiple concurrent threads, the runner was
outfitted with a "log lock" dedicated to sharing access to the output
file (when applicable). Re-use this lock when writing to standard out,
ensuring proper ordering of test result messages.
A recent extension to the test runner introduced support for running
tests in parallel using multi-threading. Following this, the runner
would incorrectly emit the "final report" before all individual test
results.
In order to emit the "final report" at the end of the output stream, the
parent thread would initialize all children and wait for availability of
a "log lock" shared by all children.
According to the documentation on the "threading" module's Lock object
[1]:
> When more than one thread is blocked in acquire() waiting for the state
> to turn to unlocked, only one thread proceeds when a release() call
> resets the state to unlocked; which one of the waiting threads proceeds
> is not defined, and may vary across implementations.
This means the primitive cannot be used by the parent thread to reliably
detect completion of all child threads.
Update the parent to maintain a reference for each child thread, and to
explicitly wait for every child thread to complete before emitting the
final result.
[1] https://docs.python.org/2/library/threading.html#lock-objects
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.
Adds a `-j`/`--workers-count` parameter to `tools/packaging/test262.py`, defaulting to `[number of cores] - 1`.
Speeds up running the test suite by about ~3x on my 4-core machine, with the SpiderMonkey shell. This could certainly be optimized more by just appending test results to per-thread lists and merging them at the end, but it's better than nothing.
It was recently decided to prefer the new `id` tag over the existing
`es5id` and `es6id` tag when authoring tests. Update the contribution
guidelines to reference the new tag.
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.
Gorkem Yakin
Leonardo Balter
Mike Pennisi
André Bargull
Rick Waldron
Till Schneidereit
Jordan Harband
Tom Schuster