These two can be combined into one test, since they are very similar. This
will allow testing the sample DST time zone as well, which is not yet
tested.
* Reject exceptional input to `isConstructor`
Prior to this commit, the `isConstructor` harness function would return
`false` when invoked with a value that lacked a [[Call]] internal
method. While it's true that such values are not constructors, there are
no tests which benefit from using `isConstructor` to make such an
assertion.
Extend `isConstructor` to throw an error when invoked with a
non-function object. Update a test which was misleadingly invoking the
function with the value `undefined`.
* fixup! Reject exceptional input to `isConstructor`
Several tests in staging use the Pacific/Apia IANA time zone to test the
behaviour of various algorithms for the case where Samoa skipped the
entire day of Dec. 30, 2011, when they switched from one side of the
International Date Line to the other. Since implementations are not
technically required to support IANA time zones, add a fake Samoa time
zone to TemporalHelpers that has the same transition, and use it in those
tests.
(The time zone isn't exactly the same as Pacific/Apia, since Samoa also
observes DST and this time zone doesn't. It's only the same for this one
transition.)
See: #3649
I made a mistake with one of the signs in one of the time zones that we
use for verifying DST handling. Luckily this didn't affect any previously
existing tests, but it affected some new tests that I'm going to add in
the next commit.
How do I know that _this_ arithmetic is correct? I feel reasonably
confident with the added test.
The `arrayContains` function has a number of deficiencies which make it
inappropriate for Test262:
- It apparently isn't very useful: despite being available for over 7
years, fewer than ten tests use it
- It's misleading: its documentation reads, "Verify that a subArray is
contained within an array." In reality, it only verifies that all the
elements of one array are present in another--order does not matter.
- It's not ergonomic for test authors: it has been misused to create
tests that were prone to false positives [1]
- It's not ergonomic for implementers: ostensibly designed for use with
`assert`, the failure messages produced by tests that use it do not
necessarily have very much context
All code in the "harness" directory adds to the total amount of
project-specific information which contributors are expected to to
learn. In light of the above deficiencies, the burden of this particular
harness file is unjustified.
Remove the harness file and its associated tests. Update the tests which
depend on it to express their expectations using alternate methods, and
strengthen the tests to assert element order wherever appropriate.
[1] https://github.com/tc39/test262/pull/3289
This reverts commit b690cb67be, reversing
changes made to 50dd431dff. This is
necessary because the reverted changeset reduced coverage by an unknown
extent.
* Introduce `assert._toString`
* Use `assert._toString` in `assert`
* Use `assert._toString` in `assert.sameValue`
* Use `assert._toString` in `assert.notSameValue`
`function nan() { return /* expression to compute NaN */ }` may not return the same implementation-distinguishable NaN value before and after JIT compilation.
* Fix bad references on tests for BigInt TypedArrays
* Remove bad conversions for BigInt TypedArray
* Cleanup the BigInt TypedArray harness file
Remove non used code (testBigIntTypedArrayConversions)
Move the constructors list to inside the exposed function, this prevents early implementations to fail before the function is called.
* Fix bad references in TypedArrays.of (BigInt)
* Remove BigInt tests from typedarray harness test
* Use BigInt for BigInt typedArrays
* Apply last fixings on BigInt TypedArray tests
* Apply fixes to last revision from @anba
Linus Groh
José Julián Espina
André Bargull
Philip Chimento
Cam Tenny
jugglinmike
rwaldron
Rick Waldron
Leo Balter
Alexey Shvayka
Gus Caplan
Ron Buckton
Adrian Heine né Lang
Mathias Bynens