* Sync test of Temporal.Calendar.p*.fields to 1750
https://github.com/tc39/proposal-temporal/pull
* add more test
* add more tests for T*.Calendar.p*.fields
* Update test/built-ins/Temporal/Calendar/prototype/fields/long-input.js
Co-authored-by: Ms2ger <Ms2ger@gmail.com>
* Update test/built-ins/Temporal/Calendar/prototype/fields/long-input.js
Co-authored-by: Ms2ger <Ms2ger@gmail.com>
* Update test/built-ins/Temporal/Calendar/prototype/fields/repeated-throw.js
Co-authored-by: Ms2ger <Ms2ger@gmail.com>
* Update test/built-ins/Temporal/Calendar/prototype/fields/reverse.js
Co-authored-by: Ms2ger <Ms2ger@gmail.com>
* Update test/built-ins/Temporal/Calendar/prototype/fields/reverse.js
Co-authored-by: Ms2ger <Ms2ger@gmail.com>
* Remove loop
* Update test/built-ins/Temporal/Calendar/prototype/fields/long-input.js
Co-authored-by: Ms2ger <Ms2ger@gmail.com>
* Update long-input.js
* Update repeated-throw.js
* Update reverse.js
* ensure the implementation check the content
make sure the validation does not happen after the looping the generator
* add test to check all valid field value
Co-authored-by: Ms2ger <Ms2ger@gmail.com>
Some tests which include function declarations designed to verify
behavior do not reference those functions. Insert the references
necessary for those functions to serve their intended purpose.
The `compareArray` utility function returns a boolean value describing
whether or not the input arrays are equivalent--it does not throw an
exception when invoked with non-equivalent arrays. Prior to this commit,
however, two tests invoked `compareArray` without inspecting its return
value, so it had no impact on the result of the test.
Update the tests to fail when the "expected" and "actual" arrays are not
equivalent.
There were a few tests already in the tree that overlapped ones that I
added in the previous commit. I've consolidated these and taken
information from the deleted ones where applicable, and improved on the
autogenerated assertion messages.
This reverts commit b690cb67be, reversing
changes made to 50dd431dff. This is
necessary because the reverted changeset reduced coverage by an unknown
extent.
While working on adding the Temporal tests from tc39/proposal-temporal I
noticed that these tests tested the same thing as each of the branding.js
tests in the same directory. This removes the duplicate tests.
Prior to this commit, a test for %TypedArray%.prototype.copyWithin
provided a TypedArray instance as the first argument. That argument that
is interpreted as a number, so in relying on the conversion, the test
verified behavior beyond what it purported to test.
Simplify the test by using the desired number value directly.
Prior to this commit, a number of tests used non-BigInt values where
BigInt value are commonly used. Although this was technically
permissible to validate the behavior under test, the atypical usage
patterns tended to obscure the tests' purpose. Replace with more
appropriate values.
Attempting to freeze the module namespace exotic object should not affect the `writable`-ity of the properties as that exercises the same `DefineOwnProperty` operation according to [`SetIntegrityLevel`](https://tc39.es/ecma262/#sec-setintegritylevel).
@erights discovered a [bug in v8](https://bugs.chromium.org/p/v8/issues/detail?id=12240) where, while the `Object.freeze` operation throws, it actually makes exported properties non-writable one by one.
At the request of @syg, I'm contributing a test against this behavior. The bug in v8 actually leads to a breakage of the objects invariants, however I'm not testing for that here as the root cause is the illegal freezing of the export.
Prior to this commit, a test for %TypedArray%.prototype.copyWithin
provided a TypedArray instance as the first argument. That argument that
is interpreted as a number, so in relying on the conversion, the test
verified behavior beyond what it purported to test.
Simplify the test by using the desired number value directly, and extend
the tests for type coercion to cover object values.
Following a recent normative change to the Resizable ArrayBuffer
proposal [1], the term "out of bounds" no longer applies to
"length-tracking" TypedArrays whose underlying ArrayBuffer has been
resized to match their byte offset.
Reflect this in the tests by renaming the condition from "out of bounds"
to "on boundary" and by adding new assertions for true "out of bounds"
conditions.
[1] https://github.com/tc39/proposal-resizablearraybuffer/pull/70
Ensure that when the ArrayBuffer of a length-tracking TypedArray is
resized to the address matching the TypedArray's byte offset, the
TypedArray is *not* considered "out of bounds."
Mike Pennisi
Phillip Mates
Ms2ger
Leo Balter
legendecas
Rick Waldron
Frank Tang
Frank Yung-Fong Tang
rwaldron
Philip Chimento
Philip Chimento
Mathias Bynens
Mathieu Hofman