* Express JSON syntax tests with multiple assertions
When written with a single assertion, this test verifies only that "one
or more" of the Unicode points produces a SyntaxError. Re-factor the
test so that parsing behavior for each code point can be tested in
isolation.
* Re-introduce assertion
ECMAScript edition 2016 relies on the Unicode standard at version 8.0.0.
As part of a larger effort to update Test262 accordingly, the assertion
for the SyntaxError resulting from the use of the Mongolian Vowel
Separator (U+180E) was removed. However, ECMA-401 (The JSON Data
Interchange Format) continues to describe "insignificant whitespace" as
follows:
> Insignificant whitespace is allowed before or after any token.
> The whitespace characters are: character tabulation (U+0009),
> line feed (U+000A), carriage return (U+000D), and space
> (U+0020)
And because ECMA262 specifies step 2 of the `JSON.parse` algorithm as
follows:
> 2. Parse JText interpreted as UTF-16 encoded Unicode points (6.1.4) as
> a JSON text as specified in ECMA-404. Throw a SyntaxError exception
> if JText is not a valid JSON text as defined in that specification.
...the use of U+180E between JSON tokens should continue to produce a
SyntaxError, regardless of ECMA262's updated Unicode standard.
* fixup! Express JSON syntax tests with multiple assertions
This changeset increases coverage for section 21, specifically "21.1 String
Objects".
* Add tests for "this" validation of String methods
* Add tests for ToNumber as used by String methods
* Add test for `length` prop of exotic String objs
* fixup! Add test for `length` prop of exotic String objs
* Improve tests for GeneratorPrototype methods
- Assert return values more consistently
- Expand tests for constraints on `this` value
* Add more tests for dynamic GeneratorFunctions
* Add more tests for GenerationFunction.prototype
* Add more tests for the GeneratorFunction object
* Extend test: GeneratorFunction.prototype.prototype
* Improve precision of tests for generator methods
Extend existing assertions to explicitly verify that execution halts at
the intended location. Correct tests which were previously asserting
this behavior in contexts that did not match their name/description.
* Remove unused variables
* fixup! Improve tests for GeneratorPrototype methods
* fixup! Improve tests for GeneratorPrototype methods
The global isNaN is not precise at all, and Number.isNaN is an ES6 feature that makes it preferrable to use assert's sameValue for NaN values, as it handles it internally using the comparison.
The prior version of this test asserted only the property's
configurability. It was also limited to the RegExp object as returned
from the RegExp constructor.
Extend the test to verify all values of the property descriptor.
Duplicate these assertions in a separate file dedicated to the RegExp
object as created from a RegExp literal.
The previous commit removed two invalid tests designed to ensure that
the RegExpPrototype object is not itself a RegExp object. Introduce a
new test to assert this detail in a way that accounts for the
possibility of host extensions.
From ECMA262, section 16:
> Except as restricted in 16.2, an implementation may provide
> additional types, values, objects, properties, and functions beyond
> those described in this specification.
Section 16.2 makes no mention of the `lastIndex` property of the
%RegExpPrototype% intrinsic. It is therefor not a violation to define
%such an "own" property.
Remove the tests that assert otherwise.
A recent web-compatability change to ECMA262 modified the semantics of
the accessor methods on the %RegExpPrototype% intrinsic--the "get"
accessors now include steps dedicated to the case where the "this" value
is the %RegExpPrototype% object itself.
Remove the tests that have been invalidated by this change, introduce
tests asserting the new behavior, and extend coverage for other possible
"this" values.
ConversionError and RegExpError tests are methods that existed on
something that preceeded a IE9 Standard. They do not exist in the
specs, at least since ES5.
It's not test262 responsibility to maintain these tests as these
features can be freely implemented by any runtime.
The original implementation of the test for the absense of a
[[PromiseState]] internal slot did not actually assert the documented
semantics. Re-implement the test to rely on the IsPromise abstract
operation (via `Promise.prototype.then`) to accurately ensure that the
object does not have a [[PromiseState]] internal slot.
In relying on the semantics of the `instanceof` operator, the original
test for the [[Prototype]] internal slot was imprecise (the assertion
could be satisfied if additional objects were incorrectly defined on the
prototype chain). Re-write the test to assert the value of the
[[Prototype]] internal slot directly.
