Because implementations are free to select any valid NaN value during
GetValueFromBuffer, tests concerning semantics for consistent NaN value
encoding cannot rely on values returned from that abstract operation.
Update the test for `%TypedArray%.prototype.map` to set the same NaN
values via `map` as set in the "control" array.
Extend tests for the `escape` and `unescape` built-ins to assert their
behavior. Rely on the latest ECMAScript draft, which specifies that
`escape` returns hexadecimal codes in upper case.
Ensure that NaN values are canonicalized consistently by all invocations
of SetValueInBuffer. Also ensure that `%TypedArray%.prototype.set` and
`%TypedArray%.prototype.slice` preserve the bit-level encoding of the
source data.
Use a set of experimentally-derived expressions known to produce NaN
values with distinct bit patterns in various platforms.
Introduce a test that asserts the equality of
`Date.prototype.toGMTString` and `Date.prototype.toUTCString`, rendering
further tests for the former's behavior unnecessary.
The RegExpBuiltinExec internal operation was modified in March of 2016
[1]: instead of referencing the `global` and `sticky` properties of the
"this" value, the algorithm now infers those values from the object's
[[OriginalFlags]] internal slot.
This change invalidated a number of tests. In cases where the change
resulted in an observable behavior, update the tests to assert the
latest specification text. In cases where the change removed a
previously-observable behavior, remove the files completely.
Specification text change set:
> 1. Assert: Type(_S_) is String.
> 1. Let _length_ be the number of code units in _S_.
> 1. Let _lastIndex_ be ? ToLength(? Get(_R_, `"lastIndex"`)).
> - 1. Let _global_ be ToBoolean(? Get(_R_, `"global"`)).
> - 1. Let _sticky_ be ToBoolean(? Get(_R_, `"sticky"`)).
> + 1. Let _flags_ be the value of _R_'s [[OriginalFlags]] internal slot.
> + 1. If _flags_ contains `"g"`, let _global_ be *true*, else let _global_ be *false*.
> + 1. If _flags_ contains `"y"`, let _sticky_ be *true*, else let _sticky_ be *false*.
> 1. If _global_ is *false* and _sticky_ is *false*, let _lastIndex_ be 0.
> 1. Let _matcher_ be the value of _R_'s [[RegExpMatcher]] internal slot.
> - 1. Let _flags_ be the value of _R_'s [[OriginalFlags]] internal slot.
> 1. If _flags_ contains `"u"`, let _fullUnicode_ be *true*, else let _fullUnicode_ be *false*.
> 1. Let _matchSucceeded_ be *false*.
> 1. Repeat, while _matchSucceeded_ is *false*
[1] https://github.com/tc39/ecma262/pull/494
This change set does not include a test for restrictions relating to
template literals because such a test already exists in the project.
While a form of this test for string literals in strict mode code
existed previously, it is less precise and relies on unrelated
semantics. Remove the previous form and replace with a more direct
version.
Assert the expected behavior of the ArraySpeciesCreate abstract
operation in the 5 Array instance methods from which it is invoked.
This change set does not include tests for ECMAScript realm
considerations because Test262 does not currently expose a mechanism for
interfacing with realms.
Add tests that assert the management of the running execution context's
LexicalEnvironment and VariableEnvironment components, as created by the
following abstract operations:
- NewDeclarativeEnvironment
- NewObjectEnvironment
- NewFunctionEnvironment
Many tests require the use of non-strict direct eval, meaning they may
not be run in strict mode. This does not effect coverage because the
semantics in these cases are not observable from strict mode code.
Some situations require the creation of a binding, but this binding has
no relevance to the test itself. In these cases, use names consisting
solely of the underscore character (`_`).
Avoid the use of Block statements wherever possible, as these trigger
the creation of additional environments which may interfere with the
behavior under test.
Closes#572
Introduce tests for new semantics for ES2015 features such as
lexically-scoped bindings. Also add tests for semantics defined in prior
editions of the specification but not yet covered in this test suite.
Limit tests in `language/expressions/call/` and `built-ins/eval/` to
only assert details that are directly related to the invocation pattern.
Re-organize all other tests within the `language/eval-code/` directory,
further categorizing each as `direct` or `indirect` as appropriate.
Remove the extraneous "executable" flag from those files which carried
it.
This harness function is not necessary in the majority of cases in which
it is used. Remove its usage to simplify tests and decrease the amount
of domain-specific knowledge necessary to contribute to the test suite.
Persist the harness function itself for use by future tests for ES2015
modules (such a helper is necessary for tests that are interpreted as
module code).
Modify the regular expression for native functions' toString value to
satisfy all test cases. Correct the test file's reference to the harness
file. Re-format the test file's assertions to aid debugging in the event
of failure.
The millisecond representation of a given Date instance is dependent on
the local system's time zone settings. In order to pass consistently
across contexts, tests for this value must take the system configuration
into account.
Introduce a test harness utility function to encapsulate these concerns.
Re-use this function across all test files that assert the exact
millisecond representation of Date instances.
Closes gh-540
Because the specific value of each constant is specified as a
host-defined approximation, only the value type may be enforced by
Test262.
Except for a small set of expected input/output pairs, both ES5 and
ES2015 define the expected return value of these methods in terms of an
"implementation-dependent approximation." This makes it inappropriate to
enforce expectations for specific values, even if expressed imprecisely.
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.
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.
Leonardo Balter
jugglinmike
Ian Halliday
Gorkem Yakin
Brian Terlson
Mythri
dtig
Jordan Harband
Michael Ficarra