The files in this patch are organized according to the following naming
scheme:
Prefix | Grammar production
-------------------|-------------------
`array-empty-` | ArrayAssignmentPattern : [ ]
`array-elision-` | ArrayAssignmentPattern : [ Elision ]
`array-rest-` | ArrayAssignmentPattern : [ Elisionopt AssignmentRestElement ]
`array-elem-` | ArrayAssignmentPattern : [ AssignmentElementList ]
`array-elem-trlg-` | ArrayAssignmentPattern : [ AssignmentElementList , Elisionopt AssignmentRestElementopt ]
Suffix | Intent
-------------------|-------
`-abpt-close-err` | The assignment evaluation returns an abrupt completion, and the iterator's `return` method throws an error
`-abpt-close-skip` | The assignment evaluation returns an abrupt completion, but IteratorClose is not invoked
`-abpt-close` | The assignment evaluation returns an abrupt completion, and IteratorClose is invoked as specified
`-get-err` | Abrupt completion returned from GetIterator
`-nrml-close-err` | The assignment evaluation completes, and the iterator's `return` method throws an error
`-nrml-close-null` | The assignment evaluation completes, and the iterator's `return` method returns a non-Object value (there is no corresponding `-abpt-` suffix because the algorithm does not reference the return value in those cases)
`-nrml-close-skip` | The assignment evaluation completes, but IteratorClose is not invoked
`-nrml-close` | The assignment evaluation completes, and IteratorClose is invoked as specified
Not all suffixes are appropriate for all productions. Suffixes have been
simplified in cases where less specificity is necessary to disambiguate
test cases.
The project's CONTRIBUTING.md was written with test authors in mind. It
contains details on non-technical metadata (e.g. "author" and "es6id"),
helper function usage, and preferred code structure. In addition, it
elides certain low-level technical details on the requirements for the
runtime environment.
Introduce a new document targeted towards those executing the tests.
Formalize all expectations regarding how the runtime environment should
be defined, how metadata should be interpreted, and how results should
be understood. This information has overlap with the CONTRIBUTING.md
file, but it also contains details that are irrelevant to test authors.
This document can serve as a more formal contract between Test262 and
the implementors who consume it. This allows Test262 to unambiguously
document future modifications to the formal requirements which in turn
supports consumers who maintain their own test harnesses.
Some tests for `eval` assert the equality of key enumeration on the
global object, comparing the ordering when the object is referenced
through eval.
Based on the test bodies and the "info" field in their metadata, these
tests appear to have been written under the mistaken impression that
erroneous creation of an environment record would be observable through
the `this` value.
In reality, the value in such cases resolves to the global object. That
renders these tests redundant and overly complex--none of the
distinctions between each test actually demonstrates a different
behavior.
Remove the redundant tests and introduce three new tests asserting the
correct resolution of the `this` keyword for direct eval code from
within the global scope and from within function scope.
Because Test262 asserts the strict equality of
`Array.prototype.toString` and `TypedArray.prototype.toString`, tests
for properties of the object do not need to be reproduced in both
location.
Ref gh-526
Files whose name ends in `_.js` are not themselves valid Test262 tests
and should not be interpreted as such by test runners.
---
The tests for the GetBindingValue method of the module Environment
Record are very minimal. This is because GetBindingValue is necessary to
assert any aspect of binding creation/initialization/mutation. In this
way, GetBindingValue is being implicitly tested by every test that
references a binding value.
Files whose name ends in `_.js` are not themselves valid Test262 tests
and should not be interpreted as such by test runners.
---
Because the tests in this patch concern declaration *instantiation*,
care has been taken to avoid asserting binding values following
evaluation. Because a given module's dependencies are evaluated prior to
the module itself, this is only observable in modules which import their
own bindings.
A separate patch dedicated to the evaluation of module code asserts the
behavior of bindings following evaluation.
---
For tests that concern the creation of a module namespace object, this
patch relies on the semantics of the `in` operator. The `in` operator
uses the [[HasProperty]] internal method and avoids testing unrelated
semantics concerning binding resolution. Those semantics should be
explicitly asserted with a separate set of tests dedicated to that
purpose.
---
One test case which is notably missing is error resulting from a cycle
due to an `import` declaration (under the current file naming scheme,
such a test might be named `instn-named-err-circular.js`). Due to the
recursive nature of ModuleDeclarationInstantiation, it is not
technically possible for a circular request to be found in step 12.c.i.
Cycles rely on at least 2 `export` declarations, and because these are
resolved *before* imports, any cycle would trigger failure prior to step
12.c.
---
One aspect of *module* resolution that makes ordering observable is the
fact that resolution can fail in two distinct ways (i.e. with a
SyntaxError or with a ReferenceError). This patch includes tests that
leverage this detail in order to assert that modules are resolved in the
correct sequence.
However, from the perspective of the ECMA-262 specification, the
ordering of *export* (e.g. binding) resolution is not observable. This
is due to restrictions on the grammar, where each export is independent.
When *export* resolution fails, it does so with instances of SyntaxError
alone, precluding the above strategy.
So while ModuleDeclarationInstantiation resolves the exports of the
module's dependencies in the following order:
1. "Indirect" exports, e.g.
- `export { x } from './y.js';`
- `export { x as z } from './y.js';`
- `import { x } from './y.js'; export { x };`
2. "Star" imports
- `import * as ns from './y.js';`
3. "Named" (my word) imports
- `import x from './y.js';`
- `import { x } from './y.js';`
- `import { x as z } from './y.js';`
Intentional failures cannot be used to discern resolution ordering.
Test specific behaviour for Integer Indexed exotic objects, WRT the
following internal methods:
- [[GetOwnProperty]]
- [[HasProperty]]
- [[DefineOwnProperty]]
- [[Get]]
- [[Set]]
- [[OwnPropertyKeys]]
As written, the example for asserting runtime errors is written with an
early error. Because the error is expected to be reported prior to
program execution, the `assert.throws` function cannot be used to detect
it.
Demonstrate the usage of the helper function with a runtime error.
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.
jugglinmike
dtig
Leo Balter
Jordan Harband
Michael Ficarra
Mythri
Dan Ehrenberg