This script is intended to identify common test file formatting errors
prior to their acceptance into the project. It is designed to support
future extensions for additional validation rules.
* Move decimalToHexString into harness instead of duplicating it in multiple files
* Optimize decimalToHexString and support numbers greater than 65535
* Replace alternative decimalToHexString function with include for decimalToHexString.js
* Add decimalToHex2String to return the string representation of a two-digit hex-number
* Replace decimalToHex2String with decimalToPercentHexString to return the percent hex-encoded string of a two-digit hex-number
* Replace two String.fromCharCode calls with a single call
* Further reduce string concatentations in decodeURI[Component] tests
* Remove unnecessary Test262Error error handling in catch-clauses
* Remove try/catch wrappings in decodeURI/encodeURI tests
* Add Function.prototype.toString tests for many function forms
* Add non-const computed property name to Function.prototype.toString tests
* Split class method tests into class-expression and class-statement tests
* Add tests for unnamed function expression forms
* Add tests for async (generator) methods in class contexts
* Add test case for Function.prototype.toString on async arrow function
* Tests for throwing a TypeError in the TypedArray constructor on a detached buffer
Detached buffer causes an exception
- If it's already detached going into the constructor
- If the byteOffset coercion causes it to be detached
Tests are valid in ES2017
* Test that TypedArray constructor throws when detaching buffer in length calculation
This test is only valid with the PR in https://github.com/tc39/ecma262/pull/852
* Rename files per review
The change is proposed in https://github.com/tc39/ecma262/pull/856
as a fix to https://github.com/tc39/ecma262/issues/855
Here, the ToNumber coercion is done only once, rather than on each
iteration. It does not appear that there were previously any
tests against repeated coercion for this parameter previously.
Tested this test against V8, which failed, as V8 implements the
current spec rather than the proposed one.
Detached buffer causes an exception
- If it's already detached going into the constructor
- If the byteOffset coercion causes it to be detached
Tests are valid in ES2017
Fixes#793
As described by @ediosyncratic:
Date(0) flows through the given algorithm to ToDateString, which should:
> Return an implementation-dependent String value that represents tv as
> a date and time in the current time zone using a convenient, human-readable form.
The string is implementation-dependent and there is nothing constraining it to use
a two-digit day-of-month (so "Thu Jan 1, 1970, 0:0:0" would be valid), much less to
position it at index 8.
Some popular JavaScript engines display violation of invariants about
property attributes for some non-standard but “web-reality” object
properties. Add tests against such violations
Closes#653Fixes#649
test/annexB/built-ins/Date/prototype/setYear/time-clip.js
test/built-ins/Date/prototype/setFullYear/new-value-time-clip.js
test/built-ins/Date/prototype/setMonth/new-value-time-clip.js
- Don't try to test time-clip at the end points, because this is near
impossible to get right (needs to consider time zone offset, dst, local
mean time because of Africa/Monrovia, etc.).
test/built-ins/DataView/prototype/setFloat64/detached-buffer-after-toindex-byteoffset.js
test/built-ins/DataView/prototype/setInt16/detached-buffer-after-toindex-byteoffset.js
- Wasn't update to expect RangeError
test/built-ins/Function/internals/Construct/derived-this-uninitialized-realm.js
- Change ClassDeclaration -> ClassExpression to get completion value
test/built-ins/Function/prototype/toString/AsyncFunction.js
- Add missing \n in expected string
- Also fixed in gh-847
test/built-ins/global/global-object.js
- Add 'var' to make test pass in strict-mode
test/language/block-scope/syntax/redeclaration-in-block/attempt-to-redeclare-function-declaration-with-function-declaration.js
- This is allowed in sloppy mode when Annex B is implemented
test/language/expressions/async-generators/expression-yield-as-statement.js
- Fix calls to then()
test/language/module-code/namespace/internals/own-property-keys-binding-types.js
test/language/module-code/namespace/internals/own-property-keys-sort.js
- Tests weren't updated after removal of @@iterator from module
namespace objects
test/language/module-code/namespace/internals/set-prototype-of-null.js
- Fix syntax error
test/language/statements/async-function/early-errors-no-async-generator.js
- No longer valid now that async iteration proposal is at stage 3
Automatic Semicolon Insertion hides an error here by transforming a long
ReturnStatement into a ReturnStatement followed by an ExpressionStatement
that is never reached. The conditions on the second line are thus never
tested.
* Ensure Proxy [[Get]] passes correct receiver
* add [[Get]] test for proxy in prototype
* diversify how traps are missing
* ensure [[Set]] passes correct receiver
* rename to match other tests
* remove extra tests
* add esid
* add description
* Add tests for prototype realm inference
* Add tests for miscellaneous realm concerns
* Add tests for realm of spec-created Errors
In some cases, Error objects produced by the specification are
observable from ECMAScript code. Among these cases, some are further
differentiated in that they occur outside of any built-in function and
may be triggered through syntactic production directly. The current
realm record is commonly interpreted incorrectly under these
circumstances.
Add tests asserting that the expected realm record is used when
constructing such Error objects.
* Add tests for realm use in ArraySpeciesCreate
* Add tests for function realm retrieval
* Add tests for cross-realm behaviors of Symbols
* Add tests for GetValue and PutValue
* Add tests for realm of spec-created Arrays
In some cases, Arrays produced by CreateArrayFromList are observable
from ECMAScript code. Among these cases, two occur outside of any
built-in function and may be triggered through syntactic production
directly. The current realm record is commonly interpreted incorrectly
under these circumstances.
Add tests asserting that the expected realm record is used when
constructing arrays.
* Add test for spec-created object
* fixup! Add tests for realm of spec-created Errors
* fixup! Add tests for realm of spec-created Errors
* fixup! Add tests for prototype realm inference
* fixup! Add tests for miscellaneous realm concerns
* Tests for new lastIndex semantics
Add and update tests for the lastIndex semantic change introduced in
https://github.com/tc39/ecma262/pull/627.
* Address comments
* Assert creation of 'arguments' object
Ensure that the 'arguments' object is created in cases where it is not
required by the body but is required by the parameters.
* Add tests for cases that disable "arguments" map
* Add tests for NewTarget override of bound function
* Add test for properties of exotic String objects
* Update tests for Proxy.[[SetPrototypeOf]]
Expand coverage for proxies' [[SetPrototypeOf]] and update tests to
verify that target's [[IsExtensible]] is not called anymore if trap
returns a falsy value.
Ref tc39/ecma262#331
* Add tests for abrupt completions during JSON.parse
Due to the use of the IsArray abstract operation, observing many of the
targeted semantics requires the use of a Proxy exotic object. Mark the
tests that require this unrelated ES2015 feature using a dedicated
"features" flag.
* 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.
According to ES2015, functions created using the FunctionDeclaration
syntax may define "own" properties named "caller" and "arguments" as
long as this is done using the AddRestrictedFunctionProperties abstract
operation.
Remove the assertions that prohibit this extension.
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.
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.
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
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.
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).