* RAB: Integrate staging tests for .byteLength method
of TypedArray.prototype
This is part of PR #3888 to make reviewing easier.
Includes changes to use the helper ./harness/resizableArrayBufferUtils.js
* RAB: Integrate staging tests for .at method
of Array.prototype and TypedArray.prototype
This is part of PR #3888 to make reviewing easier.
Includes changes to use the helper ./harness/resizableArrayBufferUtils.js
It was previously not tested what options value a custom calendar's
dateFromFields() method would be called with, when called from the
toPlainDate() method of PlainYearMonth/PlainMonthDay.
See tc39/proposal-temporal#2803
These tests were supposed to test an invalid ISO string being used as the
`calendar` property in a property bag. Instead they were testing being
used as an invalid ISO string directly where a PlainDate input was needed.
(That is also already covered elsewhere.)
Due to overlooked copy-paste errors we were creating the wrong type of
instance in these tests, and therefore testing the wrong method.
(Add blank line for consistency with the other instances of these tests.)
After rounding relative to a ZonedDateTime, we have to potentially adjust
for DST. With a time zone providing nonsensical values, the duration may
go out of range.
See: tc39/proposal-temporal#2801
This test isn't testing what the assertion message previously said it was
testing. The integer is allowed to be unsafe, but in this case its
float64-representation is out of range.
See: https://github.com/tc39/proposal-temporal/issues/2785
With test cases kindly provided by Anba, this adds test coverage for the
abrupt completion in the last step of DifferenceTemporalPlainDateTime,
where the resulting Duration components have mixed signs.
See: https://github.com/tc39/proposal-temporal/issues/2783
normalized-time-duration-to-days-range-errors.js tests for several error
cases in the AO NormalizedTimeDurationToDays. Adding assertion messages
helps to know which one you are debugging.
As per IETF, annotation keys may only consist of lowercase letters,
dashes, and digits, and an optional leading underscore. Uppercase letters
are non-syntactical. Add tests covering this.
These test cases ensure that DST disambiguation does not take place on
intermediate values that are not the start or the end of the calculation.
Note that NormalizedTimeDurationToDays is no longer called inside
Temporal.Duration.prototype.add/subtract, so a few tests can be deleted.
Other tests need to be adjusted because NormalizedTimeDurationToDays is
no longer called inside Temporal.ZonedDateTime.prototype.since/until via
DifferenceZonedDateTime, although it is still called as part of rounding.
In addition, new tests for the now-fixed edge case are added, and for the
day corrections that can happen to intermediates.
See https://github.com/tc39/proposal-temporal/pull/2760
Based on PR #3807 which had generated these tests from templates,
but was stuck due to issue #3808.
Co-Authored-By: Guillaume Emont <guijemont@igalia.com>
Co-Authored-By: Ioanna M. Dimitriou H <idimitriou@igalia.com>
Add tests to ensure that:
1. First `byteLength` isn't larger than `maxByteLength`.
2. Then `OrdinaryCreateFromConstructor` is called.
3. And finally `Create{Shared}ByteDataBlock` is called.
This adds tests specifically for every kind of case that changes due to
the tweak to the date difference algorithm: differences from a longer
month to a shorter month, when the months are adjacent, in the same year
but not adjacent, and in different years.
Also adds tests for a case that does *not* change, but would trip on an
incorrectly implemented algorithm: when the intermediate months value
falls at the end of February.
There was incidental coverage of the change to the date difference
algorithm in other tests. Those are adjusted, as well.
Normative change: https://github.com/tc39/proposal-temporal/pull/2759
Consensus in February 2024
Adapts the tests that checked arbitrarily long loops, to now check that an
exception is thrown if the loop would happen.
Adds tests that exercise the newly added checks on return values of
getPossibleInstantsFor and getOffsetNanosecondsFor that limit UTC offset
shifts to 24 hours or less.
Also updates some step numbers in related tests.
The existing tests didn't cover some edge cases where implementations
have to compute the exact result of `numerator / denominator`, where at
least one of `numerator` and `denominator` can't be exactly represented
by an IEEE-754 double precision floating point value.
"precision-exact-mathematical-values-5.js" gets added in #3961, so the
new tests from this commit start at "precision-exact-mathematical-values-6.js".
NormalizedTimeDurationToDays can no longer loop indefinitely, because at
a certain point we will hit the upper bound of MAX_SAFE_INTEGER, so rename
the test to reflect that it can loop an arbitrary but limited number of
times.
Add a test for the RangeError condition in NormalizedTimeDurationToDays
when the time zone calculates a day length that is not a safe integer
number of nanoseconds.
While editing these tests, rename them to match the current name of the AO
and make sure the step numbers are up to date. (Normally I wouldn't care
so much about that, but these tests can be pretty confusing so it's good
to be able to refer to the spec text.)
Adapts or removes tests that relied on creating durations that are now out
of range. Adds new tests for maximum in-range and minimum out-of-range
durations.
* Test closing async-from-sync iterator when resolving result promise abrupt completes.
These test new steps 6-6.a of AsyncFromSyncIteratorContinuation
as per normative changes of ecma626 PR 2600
https://github.com/tc39/ecma262/pull/2600
* Apply suggestions from code review
Co-authored-by: Kevin Gibbons <bakkot@gmail.com>
* Apply suggestions from code review
Co-authored-by: Nicolò Ribaudo <hello@nicr.dev>
* Refactoring tests to use the Async Helpers.
---------
Co-authored-by: Kevin Gibbons <bakkot@gmail.com>
Co-authored-by: Nicolò Ribaudo <hello@nicr.dev>
* Adjust existing tests to match new spec for async-from-sync iterators
Testing normative changes of ecma626 PR 2600
* Test that async-from-sync iterator closes when throw is undefined.
These test paths from newly added call to IteratorClose in step 7.c of
%AsyncFromSyncIteratorPrototype%.throw
as per normative changes of ecma626 PR 2600
* Apply suggestions from code review
Co-authored-by: Jordan Harband <ljharb@gmail.com>
* Refactoring tests to use the Async Helpers.
Addresses review comments
- https://github.com/tc39/test262/pull/3976/files#r1451071569
- https://github.com/tc39/test262/pull/3976/files#r1451075479
---------
Co-authored-by: Jordan Harband <ljharb@gmail.com>
* update constructor and toStringTag properties on Iterator.prototype
* includes cannot be empty for some reason
* update description
* add esid
* updates
* freeze Iterator.prototype
* don't try to use real GeneratorPrototype for these tests
* add tests for difference, intersection, symmetricDifference
* add tests for predicates
* more tests for ordering of calls
* fix copyrights
* add missed -0 test
* pass argument to methods, not just this
* assert methods return new objects
* typo in filename
* fix parens
* Update test/built-ins/Set/prototype/difference/add-not-called.js
Co-authored-by: Jordan Harband <ljharb@gmail.com>
* fix isSupersetOf/set-like-array.js
* add tests for negative zero with isDisjointFrom and isSupersetOf
* fix message in isSupersetOf/converts-negative-zero.js
* address comments from review
---------
Co-authored-by: Jordan Harband <ljharb@gmail.com>
A few results change because the algorithm previously used for rounding
didn't always add duration units to dates in RFC 5545 order, and we also
introduce a special case for rounding with largestUnit years or months and
smallestUnit weeks.
* Beginning of adding Set.prototype.union tests
* Fix description
* Add tests for GetSetRecord
Which also allows Set-like objects
* Add title to test descriptions
* Add test for ensuring values are appended
* Add tests for properties of union
Also: tests for RequireInternalSlot, Constructor, BuiltIns.
Added a test to ensure that -0F is converted to +0F
* Ensure Set.prototype.add is not called as part of .union
* fix lint issues
* Set subclassing and Symbol.species tests
* Set.prototype.union tests for arrays and subclass methods
* Add the Set-methods frontmatter feature flag
* Add additional Set.prototype.union test for edge cases
* Update test/built-ins/Set/GetSetRecord/keys-is-callable.js
Co-authored-by: Kevin Gibbons <bakkot@gmail.com>
* Use compareArray() for assertions
* Remove class field syntax
* Remove unused args
* Update test/built-ins/Set/prototype/union/subclass-receiver-methods.js
Co-authored-by: Jordan Harband <ljharb@gmail.com>
* Return original 'add'
* address comments
* add one more mutation in the evil mutating iterator test
* address further comments
---------
Co-authored-by: Kevin Gibbons <bakkot@gmail.com>
Co-authored-by: Jordan Harband <ljharb@gmail.com>
Co-authored-by: Ms2ger <Ms2ger@igalia.com>
In order to fixtc39/proposal-temporal#2563, we added invocations of
BalanceDurationRelative after some invocations of RoundDuration. These
cause observable calendar calls, which must be accounted for in some
existing tests.
See https://github.com/tc39/proposal-temporal/issues/2563
The old behaviour was encoded in one test in staging, but the behaviour of
largestUnit in duration rounding has changed since that test was written.
Therefore I'm assuming that toString() should've been updated when that
happened.
Unicode 15.1 added the following "simple" case-folding entries:
```
1FD3; S; 0390; # GREEK SMALL LETTER IOTA WITH DIALYTIKA AND OXIA
1FE3; S; 03B0; # GREEK SMALL LETTER UPSILON WITH DIALYTIKA AND OXIA
FB05; S; FB06; # LATIN SMALL LIGATURE LONG S T
```
Built-in non-ISO calendars require either monthCode/day, or month/day plus
some form of year specification.
This adds test coverage for each of the categories listed in
https://github.com/tc39/proposal-temporal/issues/2664, of which some must
currently reside in the test/intl402/ folders.
We'll do this for now, then separately work on migrating all of the tests
that require a non-ISO8601 calendar but aren't dependent on it being any
particular calendar.
In the AO DisambiguatePossibleInstants, a PlainDateTime instance is passed
to user code. This instance should have the built-in ISO 8601 calendar.
Here are some tests that ensure it does.
See tc39/proposal-temporal#2671.
In PlainYearMonth arithmetic, we need to find the end of the month when
adding a negative duration or subtracting a positive one. This end of the
month can be out of range.
Test case based on one provided by Anba. See issue:
https://github.com/tc39/proposal-temporal/issues/2700
Two issues:
1. There was a typo, the first `gen` should have been `genFn`.
2. And the last `toString` result should be `'[object Generator]'`,
because `Object.getPrototypeOf(gen) == genFn.prototype`. And the
`@@toStringTag` property of `genFn.prototype` is inherited from
`Generator.prototype[@@toStringTag]`.
That also means the "iterator-helpers" flag isn't needed for this test.
This removes several loopholes where it was possible to return particular
values from user calls that would cause infinite loops, or calculate
zero-length days.
This allows removing several tests, as calendar.dateAdd() is no longer
called in several places, and it's no longer possible to create a
situation where BigInt arithmetic is observable in NanosecondsToDays.
Note the monkeypatch of getPossibleInstantsFor in test/built-ins/Temporal/
TimeZone/prototype/getInstantFor/argument-builtin-calendar-no-array-
iteration.js.
Other than that, all the tests are basically identical.
Adds new tests to order-of-operations.js in Duration.round and
Duration.total, to exercise the code path where previous to this normative
change, relativeTo would have been converted to PlainDate 3x and 2x,
respectively.
This shortcut path now exists in all round(), since(), and until()
operations.
In Instant, PlainDate, PlainDateTime, and PlainTime, the change isn't
observable, so no tests could be added. This adds test coverage for
- Duration.p.round()
- PlainYearMonth.p.since()
- PlainYearMonth.p.until()
- ZonedDateTime.p.round()
- ZonedDateTime.p.since()
- ZonedDateTime.p.until()
As well as a few cases where we are testing that certain calendar methods
get called during a round operation, but previously were doing so with
options that now become a no-op and no longer call those calendar methods.
In those cases, round to 2 ns, rather than 1 ns.
The behavior of `/\p{RGI_Emoji}/v` and other properties of strings depends on the Unicode & Emoji version being used in the JavaScript engine. This patch adds tests verifying new additions to `RGI_Emoji` for each release of the Unicode Emoji standard are correctly matched.
Adds tests that verify that Instant strings cannot include offset time
zone annotations with sub-minute units.
Also removes a few staging test cases that, due to a polyfill bug, were
incorrectly passing.
This commit verifies that ISO strings with sub-minute offsets cannot
be parsed into time zone identifiers. This was a change introduced in
the recently-merged tc39/proposal-temporal#2607, but tests for this case
were missing from #3862 (the tests for that PR).
I noticed in codecov results on an unrelated PR that this case wasn't
being tested, so fixing that mistake now.
I noticed a small test hole in codecov: we weren't testing
Temporal.Instant parsing with trailing zeroes in the offset.
I also didn't see fractional offset testing, so added that too.
Codecov showed that PlainTime strings like "09:00:00Z[UTC]" or
"09:00:00Z" were not being tested. This commit fills that gap.
It'd probably be good to make similar changes for other Plain* types,
but Codecov didn't complain about them so they may be covered
via other tests so it was less urgent.
This commit fills a test hole found by Codecov: we weren't checking for
the case of a custom time zone whose `id` property returns a non-string
value.
Note that the `id` property is only read in a few places, all on the
ZonedDateTime prototype: `until`, `since`, `equals`, `toString`,
`toLocaleString`, `toJSON`, and `timeZoneId`.
Edits Temporal tests to account for changes in
https://github.com/tc39/proposal-temporal/pull/2574.
This PR stops coercing non-string primitive inputs to strings
in Temporal methods, to avoid cases where numbers
are coerced to syntactically valid but often unexpected
string results.
* Add tests for the new PrepareTemporalFields behavior for all direct callers
See https://github.com/tc39/proposal-temporal/pull/2570
* Add tests for the new PrepareTemporalFields behavior for indirect callers through ToTemporalDate
* Add tests for the new PrepareTemporalFields behavior for indirect callers through ToTemporalDateTime
* Add tests for the new PrepareTemporalFields behavior for indirect callers through ToTemporalZonedDateTime
* Add tests for the new PrepareTemporalFields behavior for indirect callers through ToTemporalYearMonth
* Add tests for the new PrepareTemporalFields behavior for indirect callers through ToTemporalMonthDay
* Add tests for the new PrepareTemporalFields behavior for indirect callers through ToRelativeTemporalObject
* Add tests for the new PrepareTemporalFields behavior for indirect callers through AddDurationToOrSubtractDurationFromPlainYearMonth
drop:
property descriptor
name
length
[[Prototype]]
is a function
is not constructible
result instanceof Iterator
limit is given a non-primitive that needs to be converted to a number
through valueOf
through toString (array)
limit coercion to number throws
limit converts to NaN
same as limit not supplied
limit behaves properly
limit < number of values
limit = number of values
limit > number of values
gets the next method from the underlying iterator only once
underlying iterator has throwing next getter
underlying iterator next throws when advancing past dropped items
underlying iterator is advanced after calling drop
underlying iterator is closed after calling drop
underlying iterator is already closed
underlying iterator next returns non-object
underlying iterator next returns object with throwing done/value getters
underlying iterator return is never called when result iterator is closed
every:
property descriptor
name
length
[[Prototype]]
is a function
is callable
is not constructible
result is a Boolean
predicate is non-callable
iterator already exhausted
called on non-object
called on object with "next" method
called on object with non-callable "next" method
predicate returns non-Boolean
predicate returns truthy for all iterated values
returns true
predicate returns truthy for some iterated values but then falsey for at least one iterated value
returns false
iteration stops
iterator is closed
predicate returns falsey immediately
returns false
iteration stops
iterator is closed
predicate throws
every throws
iterator is closed
predicate throws then iterator close also throws
predicate this value is undefined
predicate is passed the yielded value as the first parameter and a counter as second parameter
gets the next method from the iterator only once
iterator has throwing next getter
iterator has throwing return getter
iterator next throws
iterator return throws
iterator next returns non-object
iterator next returns object with throwing done/value getters
Co-authored-by: Michael Ficarra <mficarra@shapesecurity.com>
Co-authored-by: Jordan Harband <ljharb@gmail.com>
As per IETF review, an IXDTF string (ISO 8601 with annotations) is no
longer valid if it contains more than one u-ca annotation and at least one
of the annotations is marked critical.
Removes tests where such a string was assumed to be valid, and adds new
ones with a few variations on invalid strings.
This change affects how PlainYearMonth's add and subtract behave. They
now ignore daysInMonth reimplementations in the calendar, and they call
dateadd() a different number of times.
See https://github.com/tc39/proposal-temporal/issues/1315
Add order-of-operations tests for:
- Temporal.ZonedDateTime.p.getISOFields()
- Temporal.ZonedDateTime.p.round()
- years with ZonedDateTime relativeTo in Temporal.Duration.p.round()
- years with ZonedDateTime relativeTo in Temporal.Duration.p.total()
- property Gets on receiver in Temporal.PlainDateTime.p.with()
- ZonedDateTime difference methods with largestUnit being a time unit
- Duration.compare with no units higher than hours
Before the issue is fixed, rounding a duration such as 'PT2400h' with
months as largest unit fails to balance it properly and gives a result
with days being the largest unit. The test ensures that such rounding
happens properly.
Previously, "nested" calendar property bags were unwrapped up to one
level. That is, this object:
{
calendar: {
// ...Temporal.Calendar methods
}
}
would not be considered to implement the Calendar protocol, but would have
its calendar property used instead, if it were passed to an API that
required a Calendar protocol object.
These nested property bags are no longer supported. Discussion:
https://github.com/tc39/proposal-temporal/issues/2104#issuecomment-1409549753
Corresponding normative PR:
https://github.com/tc39/proposal-temporal/pull/2485
Previously, "nested" time zone property bags were unwrapped up to one
level. That is, this object:
{
timeZone: {
// ...Temporal.TimeZone methods
}
}
would not be considered to implement the TimeZone protocol, but would have
its timeZone property used instead, if it were passed to an API that
required a TimeZone protocol object.
These nested property bags are no longer supported. Discussion:
https://github.com/tc39/proposal-temporal/issues/2104#issuecomment-1409549753
Corresponding normative PR:
https://github.com/tc39/proposal-temporal/pull/2485
Compare semantics for custom time zones that _don't_ extend
Temporal.TimeZone (and therefore don't have the internal slot) use the
value of the .id property, instead of calling toString().
Normative PR: https://github.com/tc39/proposal-temporal/pull/2482
This is the replacement of the old API with the new API, .timeZoneId and
.getTimeZone(). Semantics will be corrected in the following commit.
Normative PR: https://github.com/tc39/proposal-temporal/pull/2482
Compare semantics for custom calendars that _don't_ extend
Temporal.Calendar (and therefore don't have the internal slot) use the
value of the .id property, instead of calling toString().
Normative PR: https://github.com/tc39/proposal-temporal/pull/2482
In several tests involving custom calendars, we need to change the
implementation of dateFromFields/monthDayFromFields/yearMonthFromFields so
that the returned object gets the receiver as its calendar after chaining
up to the builtin implementation.
Normative PR: https://github.com/tc39/proposal-temporal/pull/2482
Has several effects on existing tests:
- Remove PlainTime from various tests that extract a Temporal.Calendar
instance from another Temporal object.
- Remove Temporal.PlainTime.prototype.calendar property.
- Remove calendar property from object returned from
Temporal.PlainTime.prototype.getISOFields().
- Ignore calendar annotation when converting ISO string to PlainTime.
Normative PR: https://github.com/tc39/proposal-temporal/pull/2482
This contains a few more tests for Array.fromAsync, in addition to what
has already been merged and what is under review at #3791.
This covers the following items from the testing plan at #3725:
- Success cases
- Creates promise
- Create new array/arraylike in promise (with length = length property)
- Input
- Invalid input values
- nonconforming object (arraylike without length, missing keys)
- Covered by polyfill tests
- Result promise rejects if length access fails (non-iterable input)
- Unaffected by globalThis.Symbol mutation (non-iterable)
- this-value
- this-value is a constructor
- this-value is not a constructor
- If this is a constructor, and items doesn't have a Symbol.iterator,
returns a new instance of this
- Iterator closed when property creation on this fails
- Returned promise rejects when ^
- Other tests
- Error is thrown for all CreateDataProperty fails
- Non-writable properties are overwritten by CreateDataProperty
- Input with missing values
Co-authored-by: Ms2ger <Ms2ger@igalia.com>
This adds copies of the tests added in the previous commit, to the
respective BigInt folders, editing them to use the testBigIntTypedArray
helper instead of the testTypedArray helper.
See: #3723
- normal case with synchronous and asynchronous mapfn
- a non-callable value is passed as mapfn
- behaviour of various values of thisArg in strict and sloppy mode
- mapfn result is awaited once per iteration
- iterator is closed when mapfn throws
Tests for the process of calculating the reference ISO day for
Temporal.PlainYearMonth and the reference ISO year for
Temporal.PlainMonthDay.
Normative PR: https://github.com/tc39/proposal-temporal/pull/2475
In https://github.com/tc39/proposal-temporal/pull/2474, which achieved
consensus at the TC39 plenary meeting of 2023-01-31, the implementation-
defined steps for Temporal.Calendar.prototype.mergeFields had their
language tightened, to better specify what implementations must do.
This adds tests covering the new spec language, and moves one related test
out of staging.
In since() and until() methods, we copy the options object with
CopyDataProperties. Previously, its properties could be read in more than
one place (the method itself, and the calendar method), triggering user
code each time. Now, we pass around null-prototype objects with only data
properties.
See https://github.com/tc39/proposal-temporal/pull/2447
Previously in a few cases (calendar units in Duration) the value for the
roundingIncrement option had no upper limit, other than having to be
finite. These tests cover a normative change limiting it to 1e9.
Normative PR: https://github.com/tc39/proposal-temporal/pull/2480
Philip Chimento
Ioanna M Dimitriou H
Mathias Bynens
Shu-yu Guo
Adam Shaw
Sosuke Suzuki
SUZUKI Sosuke
Philip Chimento
André Bargull
Kevin Gibbons
Ron Buckton
Guillaume Emont
Cam Tenny
Aditi
Nicolò Ribaudo
Michael Ficarra
Ioanna M. Dimitriou H
Rezvan Mahdavi Hezaveh
Jordan Harband
Linus Groh
Anthony Frehner
Richard Gibson
Rezvan Mahdavi Hezaveh
Peter Klecha
Peter Klecha
Justin Grant
Rick Waldron
Aditi
José Julián Espina
Ms2ger