Test specific behaviour for Integer Indexed exotic objects, WRT the
following internal methods:
- [[GetOwnProperty]]
- [[HasProperty]]
- [[DefineOwnProperty]]
- [[Get]]
- [[Set]]
- [[OwnPropertyKeys]]
As written, the test for `Math.random` would pass if the runtime
erroneously produced a non-numeric value. Add the necessary assertions
to guard against this case.
The runtime semantics of this statement are host-defined and therefore
untestable, but the statement's affect on the formal grammar should be
consistent across all implementations.
V8 ran into an issue where the YAML parser our test setup is using
didn't understand the newline, and failed to parser the negative
test expectation below, causing the test to fail. This patch fixes
the issue.
Assert that ImportDeclaration and ExportDeclaration match only the
ModuleItem symbol.
According to the definition of HostResolveImportedModule, it is
acceptable for an implementation to throw a SyntaxError in the event
that a requested module can neither be found nor created:
> If a Module Record corresponding to the pair referencingModule,
> specifier does not exist or cannot be created, an exception must be
> thrown.
In order to reliably detect a SyntaxError in response to the correct
interpretation of the grammar (and not a SyntaxError from an *incorrect*
interpretation of the grammar followed by a failure to resolve the
requested module), the ModuleSpecifier of ExportDeclarations should
describe a valid resource.
- Prefix file names to explicitly describe the "head" position
- Remove statement name suffix as this information is reflected by each
file's location within the file hierarchy
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
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.
Because these tests concern the behavior of the PromiseReactionJob
abstract operation itself, they should avoid assumptions about the
correct implementation of that operation. Specifically: they should not
rely on the behavior of abupt completions returned from "reaction
handler" functions.
Re-implement tests to express control flow expectations using the
`$DONE` function only.
These tests concern the behavior of PerformPromiseThen for settled
Promises. That abstract operation behaves differently for pending
promises, so the file naming scheme should reflect this distinction in
order to support the future implementation of additional tests.