* 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."
Prior to this commit, the modified tests used the strict equality
operator to compare computed values with negative zero. Due to the
semantics of that operator, these tests would spuriously pass if the
value under test was in fact positive zero.
Update the tests to be more precise by instead asserting equality with
the `assert.sameValue` utility method (since that method correctly
distinguishes between negative zero and positive zero).
Prior to this commit, the modified test included two different
expressions in positions that were meant to describe the same
expression. This meant that the value of the intended expression was
only partially verified.
Correct the test to fully verify the value of the expression.
Prior to this patch, two distinct failure cases would produce the same
generic error message. Refactor the test logic to report the specific
condition which trigger failure.
A recent normative change to the Resizable ArrayBuffer modified the
criteria for a TypedArray becoming "out of bounds." Following the
change, TypedArrays which track the length of their underlying
ArrayBuffer instance are no longer considered "out of bounds" when the
ArrayBuffer is resized such that its size matches the TypedArray's
offset exactly.
https://github.com/tc39/proposal-resizablearraybuffer/pull/70
The majority of this patch's changes extend coverage to include cases
for both "on boundary" and "out of bounds" without reflecting any new
semantics. Two changes describe observable differences in the new
version of the algorithm:
- out-of-bounds-when-species-retrieved-different-type.js
- out-of-bounds-when-species-retrieved-same-type.js
The tests for the "Array findFromLast" proposal were originally authored
based on related tests that had already been merged to the repository's
`main` branch [1]. While those new tests were under review, a number of
tests for the Resizable ArrayBuffer proposal were found to be incorrect
[2]. The problem was fixed for the tests in `main`, but because the
corresponding tests for "Array findFromLast" were not yet merged, the
error persisted there [3].
Apply the same correction to the new tests.
[1] https://github.com/tc39/test262/issues/3111
[2] https://github.com/tc39/test262/pull/3113
[3] https://github.com/tc39/test262/pull/3045
Extend coverage to include the property's writability and
configurability. Use the conventional `verifyProperty` harness function
to consolidate tests.
Extend coverage to include the property's writability, configurability,
and value. Use the conventional `verifyProperty` harness function to
consolidate tests.
In each case, it's the scalar value associated with the "description" key.
Normally in test262, this is written in either:
- block notation (indicated by '>' or '|'), or
- flow notation, single-line, on the same line as the key.
In the cases addressed by this PR, the value is instead written in:
- (1x) flow notation, *multi*-line, or
- (2x) flow notation, single-line, on the line *after* the key.
These are valid YAML, but they're styles that test262 doesn't otherwise use,
so could conceivably confuse people or harnesses.
This PR changes them to block notation.
The following proposed change modifies the semantics this test was
originally written to verify:
Normative: Allow null or undefined in Reference Records
https://github.com/tc39/ecma262/pull/2267
Since https://github.com/tc39/ecma262/pull/1490, the "length" and "name"
properties of a class are defined before any static methods. This is
tested by #2057, in test/language/computed-property-names of all places.
At the same time, static methods with "name" as the name would overwrite
the original property, but retain the original property enumeration
order. This was not previously tested. In fact, the overwriting behavior
was not tested at all for the "length" property.
This commit mends both holes in test coverage.
* Temporal.now.plainDateTime: import tests from prop
* Add required metadata
* Correct invalid test
Ensure the error is thrown due to the invocation of the provided method.
Add a separate test to verify how the method is invoked.
* Remove duplicated assertions
* Improve coverage
* Rewrite test to focus on Calendar parameter
The observable interactions with the "timeZone" parameter are verified
by another test which is named for that purpose.
* Remove non-standard test
This test's title suggests that it was intended to verify the behavior
when the "calendar" parameter was undefined. The expected behavior in
that case depends on the presence of a builtin calendar named
"undefined." Test262 cannot definitively assert the presence or absence
of such a calendar.
In contrast to the title, the test body actually uses the calendar name
"japanese." Test262 cannot definitively assert the presence or absence
of such a calendar.
* Add tests for "Class Static Init. Blocks" proposal
This proposal is currently at "stage 3" in TC39's standardization
process.
* fixup! Add tests for "Class Static Init. Blocks" proposal
* Correct identifier reference
* Update tests for grammar
* Update tests for identifiers
* Add tests for scope derivation
* ResizableArrayBuffer: TypedArray.prototype.set
* Resizable ArrayBuffer: TypedArray methods
The files in this patch are highly similar. Only the test for
`TypedArray.prototype.copyWithin` was written manually. The others were
generated from that test via the following script:
#!/bin/bash
set -eu
names_cb='
every
filter
find
findIndex
forEach
map
reduce
reduceRight
some
'
names_num='
at
fill
includes
indexOf
join
lastIndexOf
slice
'
names_none='
entries
values
keys
reverse
sort
toLocaleString
values
'
for name in $(printf "${names_cb} ${names_num} ${names_none}"); do
lower=$(echo ${name} | tr '[:upper:]' '[:lower:]')
if echo "$names_cb" | grep -xq $name; then
value='() => {}'
elif echo "$names_num" | grep -xq $name; then
value='0'
else
value=''
fi
if [[ "${name}" == 'at' ]]; then
features_addition='TypedArray.prototype.at, '
else
features_addition=''
fi
sed \
-e "s/copywithin/${lower}/g" \
-e "s/copyWithin/${name}/g" \
-e "s/${name}(.*);/${name}(${value});/g" \
-e "s/resizable-arraybuffer/${features_addition}resizable-arraybuffer/g" \
./test/built-ins/TypedArray/prototype/copyWithin/return-abrupt-from-this-out-of-bounds.js \
> ./test/built-ins/TypedArray/prototype/${name}/return-abrupt-from-this-out-of-bounds.js
done
* Add "feature" for "Resizable ArrayBuffer" proposal
* Resizable ArrayBuffer: DataView methods
The files in this patch are highly similar. Only the test for
`DataView.prototype.getBigInt64` and `DataView.prototype.setBigInt64`
were written manually. The others were generated from those files via
the following script:
#!/bin/bash
set -eu
names='
BigUint64
Float32
Float64
Int16
Int32
Int8
Uint16
Uint32
Uint8
'
for name in ${names}; do
lower=$(echo ${name} | tr '[:upper:]' '[:lower:]')
if [ ${name} == 'BigUint64' ]; then
replace_bigints=''
else
replace_bigints='-e s/\b\([0-9]\+\)n\b/\1/g'
fi
sed \
-e "s/getbigint64/get${lower}/g" \
-e "s/getBigInt64/get${name}/g" \
${replace_bigints} \
./test/built-ins/DataView/prototype/getBigInt64/resizable-buffer.js \
> ./test/built-ins/DataView/prototype/get${name}/resizable-buffer.js
sed \
-e "s/setbigint64/set${lower}/g" \
-e "s/setBigInt64/set${name}/g" \
${replace_bigints} \
./test/built-ins/DataView/prototype/setBigInt64/resizable-buffer.js \
> ./test/built-ins/DataView/prototype/set${name}/resizable-buffer.js
done
* Fix test for only {localeMatcher: "lookup"}
The expectation that "sr-Thai-RS" would be returned is only true with the
9.2.2 BestAvailableLocale ( availableLocales, locale )
https://tc39.es/ecma402/#sec-bestavailablelocale
algorithm used by 9.2.3 LookupMatcher ( availableLocales, requestedLocales )
https://tc39.es/ecma402/#sec-lookupmatcher
The default for localeMatcher is "best fit" but not "lookup" for all Intl objects.
And for 9.2.4 BestFitMatcher ( availableLocales, requestedLocales )
https://tc39.es/ecma402/#sec-bestfitmatcher
It may not match "sr-Thai-RS" for "sr" and return ["de", "zh-CN"] instead. Therefore, we need to change this test to only test on {localeMatcher: "lookup"}
* Add option to getLocaleSupportInfo
Needed to test different localeMatcher
* only test for "lookup" localeMatcher
* Get the info based on the localeMatcher
* pass in localeMatcher to getLocaleSupportInfo
These tests support the following normative change
"Normative: Allow null or undefined in Reference Records"
https://github.com/tc39/ecma262/pull/2267
The tests concerning the `delete` operator increase coverage to verify
behavior which, though related, is not altered by the normative change.
These tests are intended to guard against regressions as engines
implement the new semantics.
* Add tests for Object.hasOwn
* Update test/built-ins/Object/hasOwn/length.js
Co-authored-by: Jordan Harband <ljharb@gmail.com>
* Update test/built-ins/Object/hasOwn/name.js
Co-authored-by: Jordan Harband <ljharb@gmail.com>
* Fixup comments for Object.hasOwn
* Add Object.hasOwn descriptor test
* use assert.sameValue with true instead of assert()
* remove extra semicolons
* Remove old $ERROR style tests from hasown
* Fix thrown error type in hasown tests
* Fix incorrect test cases
Co-authored-by: Jordan Harband <ljharb@gmail.com>
Additionally, update test metadata and introduce two new tests to
complete coverage.
Reference: "Normative: Make B.1.{1,2} normative"
https://github.com/tc39/ecma262/pull/1867
* Add basic tests for weekInfo
* Add basic tests for textInfo
* Add basic tests for timeZones
* Add basic tests for numberingSystems
* Add basic tests for hourCycles
* Add basic tests for collations
* Add basic tests for calendars
* Add feature for Intl.Locale-info
* add validation to branding tests for locale-info
Add additional assertion to branding tests for proposal-intl-locale-info
to make sure they don't pass spuriously when the proposal is not
implemented.
Minimize the code provided to the `assert.throws` utility in order to
reduce the possibility of false positives and to improve failure
messages in non-conforming runtimes.
These tests were designed to test the built-in "Promise.race Resolve
Element function," but ECMA262 does not describe such a function.
Contrary to the test's description, the function under test is created
by the InstantiateArrowFunctionExpression abstract operation. The
following tests verify most of the details directly (only the function
object's extensibility was not already tested by the existing tests):
- test/language/expressions/arrow-function/name.js
- test/language/expressions/arrow-function/throw-new.js
- test/language/expressions/arrow-function/prototype-rules.js
The definition of the built-in resolving functions is closely related,
but Test262 already includes tests for the corresponding concerns:
- test/built-ins/Promise/resolve-function-extensible.js
- test/built-ins/Promise/resolve-function-name.js
- test/built-ins/Promise/resolve-function-nonconstructor.js
- test/built-ins/Promise/resolve-function-prototype.js
Remove the tests and introduce one additional test to preserve coverage
while improving discoverability.
Leo Balter
legendecas
Rick Waldron
Frank Tang
Ms2ger
Frank Yung-Fong Tang
Mike Pennisi
rwaldron
Philip Chimento
Philip Chimento
Mathias Bynens
Phillip Mates
Mathieu Hofman
Andreas Woess
Richard Gibson
Jan Štola
André Bargull
Linus Groh
Michael Dyck
Mickey Rose
Shu-yu Guo
Meir Blachman
Wenlu Wang
devsnek
Timothy Gu
Nicolò Ribaudo
Kate Miháliková
Dan Clark
Ujjwal Sharma
Jamie Kyle
Alexey Shvayka
Stuart Cook