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.
Leonardo Balter
Gorkem Yakin
Jordan Harband
Mike Pennisi
André Bargull
Rick Waldron
Till Schneidereit