Including:
- 21.2.4.2 get RegExp [ @@species ]
- 21.2.5.3 get RegExp.prototype.flags
- 21.2.5.4 get RegExp.prototype.global
- 21.2.5.5 get RegExp.prototype.ignoreCase
- 21.2.5.7 get RegExp.prototype.multiline
- 21.2.5.10 get RegExp.prototype.source
- 21.2.5.12 get RegExp.prototype.sticky
- 21.2.5.15 get RegExp.prototype.unicode
- 22.1.2.5 get Array [ @@species ]
- 23.1.2.2 get Map [ @@species ]
- 23.2.2.2 get Set [ @@species ]
- 24.1.3.3 get ArrayBuffer [ @@species ]
- 24.1.4.1 get ArrayBuffer.prototype.byteLength
- 24.2.4.1 get DataView.prototype.buffer
- 24.2.4.2 get DataView.prototype.byteLength
- 24.2.4.3 get DataView.prototype.byteOffset
- 25.4.4.6 get Promise [ @@species ]
- B.2.2.1.1 get Object.prototype.__proto__
- B.2.2.1.2 set Object.prototype.__proto__
Skipped TypedArray tests in order to avoid an early test strategy definition for them.
The "monkeyYaml" parser is intended to serve as a lightweight fallback
to Python's standard YAML parser in contexts where the latter is not
available. Any intentionally-simplified implementation will necessarily
exhibit non-standard behavior for different input, so not all input
accepted by the standard parser will be accepted by "monkeyYaml". If
loaded exclusively in fallback situations, these edge cases can only be
identified (and debugged) in the environments that require the fallback.
This has allowed developers to unknowingly author tests that cause
errors.
Update the test runner to use "monkeyYaml" in all cases, ensuring more
consistent behavior across contexts and precluding this class of
regression.
In ECMAScript 5, assignment to a non-reference value throws a runtime
ReferenceError. ECMAscript 6 specifies an early ReferenceError in these
cases. Tests for this behavior have been authored to pass in both cases.
Simplify these tests to describe and assert the early error.
Some JavaScript source files are only relevant in the context of the
Test262 website. They should not be explicitly included by individual
tests, so their presence in the `harness/` directory alongside "include"
files is misleading.
Move the scripts to a location within the `website/` directory to
better-reflect their intended use. Update the relevant HTML templates
with the new locations.
Although test files once expressed dependencies on external files using
a global `$INCLUDE` function, that pattern was removed in favor of
declarative meta-data [1].
Remove the associated logic from the Python runner and the browser.
[1] See commit d4354d14d5.
The `fnExists` function defines a generic way to determine if any number
of values are function instances. Because it is only used by a single
test, the additional complexity required by the generalized code (and
the organizational drawbacks to maintaining another "include" file) are
not justified. Remove the file and update the test to assert the
function's existence directly.
The `environment.js` file has been empty since its initial introduction
to this project [1]. It has no effect on any of the contexts in which it
is currently referenced, so it may be safely removed.
[1] be82787a00
This test's description concerns the behavior of `Promise.all` when the
IteratorStep abstract operation fails due to an abrupt completion
returned by the iterator's `next` method. The test body did not actually
assert that functionality.
Update the test body to correctly define the requisite iterator and
assert that the specific error created is the one thrown from the
invocation of `Promise.all`
Some tests specifically concern the application of the `use strict`
directive as it appears in JavaScript source code. These tests should
*not* be run with the `onlyStrict` flag because relying on the test
runner to enable strict mode makes the semantics of the source code
irrelevant. Update these tests to use the `noStrict` flag.
Other tests concern language semantics that are only valid in strict
mode, but the mechanism for enabling strictness is inconseqential.
Update these tests to use the `onlyStrict` flag and remove any redundant
`use strict` directive prologues contained within.
Still other tests are valid both within and outside of strict mode.
In keeping with the majority of other tests, do not specify any
restrictions on the environments in which these tests may be run.