This looks like a bug: resolveAsyncGC() is supposed to succeed if the
thrown value is asyncGC.notCollected, but instead it would call $DONE()
twice. An added "return" prevents that.
It's possible for an async test to throw a Symbol (harness/async-gc.js
does this.) The Symbol ends up getting passed to $DONE in a
.then($DONE, $DONE) call. Previously, $DONE would then throw an exception
due to not being able to convert the Symbol to a string.
This adds tests to WeakMap, WeakSet, WeakRef, and FinalizationRegistry for
Symbols as weakly-held values. Regular symbols and well-known symbols are
both tested. These tests correspond to existing tests for Objects as
weakly-held values, but are put in separate files so that they can be
filtered out with the "symbols-as-weakmap-keys" feature flag.
Registered symbols are not allowed; this is already tested in the "cannot-
be-held-weakly" tests.
See: #2850
There are many existing tests for WeakMap, WeakSet, WeakRef, and
FinalizationRegistry using Objects as weak values. For symbols-as-weakmap-
keys, we'll want to write tests that parallel these for Symbol keys.
Change the descriptions and filenames of these tests to describe their new
scope of only Object weak values.
Update the front matter of these tests while we're at it, to reflect the
changes to the spec text that the symbols-as-weakmap-keys brings in. (In
some cases, remove irrelevant bits of the front matter.)
See: #2850
WeakMap, WeakSet, WeakRef, and FinalizationRegistry all had tests
verifying what would happen if they were called with a value that wasn't
allowed as a weak value: before this proposal, that was a non-Object.
Now, allowed weak values are Objects, well-known Symbols, and unregistered
Symbols. That leaves registered Symbols that are still not allowed as weak
values.
This commit updates those tests to use a registered Symbol instead of an
unregistered Symbol; they should still pass, regardless of whether the
implementation has implemented symbols-as-weakmap-keys yet.
The tests are renamed as appropriate.
Also updates the frontmatter to the most current spec text, including the
CanBeHeldWeakly abstract operation.
See: #2850
This test is duplicated by WeakSet/prototype/add/value-not-object-throw.js
Originally taken from Rick's draft commit for symbols-as-weakmap-keys
tests.
See https://github.com/tc39/proposal-temporal/pull/2316 which eliminated
an observable call to Array.prototype[Symbol.iterator]() in the case where
a calendar's 'fields' property was undefined.
The best way I've thought of to test this is to monkeypatch the
Array.prototype[Symbol.iterator]() method to make it throw. In some cases,
where we are actually expected to iterate the return value from a
Temporal.TimeZone's getPossibleInstantsFor() method, we have to provide a
custom method for that as well, that returns a non-Array iterable so we
don't call the patched Array.prototype[Symbol.iterator]().
This normative change reached consensus at the July 2022 TC39 plenary
meeting.
The programmer always gets the last word over how the string is
interpreted, since otherwise it's not possible to make any guarantees
about the offset option. (This is the "out-of-band" mechanism mentioned in
the IETF draft.) Add a test for this.
Based on the improvements just made to the calendarName option, improve
the tests for the timeZoneName option of ZonedDateTime.prototype.toString
as well.
Since we are going to be adding a new test for calendarName: "critical",
take the existing tests for various values of the calendarName option, and
regularize them. Previously, depending on which type's toString() method
was under test, the tests had various degrees of thoroughness, and some
were only present in staging.
See https://github.com/tc39/proposal-temporal/pull/2397
Adds tests for ISO strings with more than one time zone annotation. These
are not syntactically correct according to the grammar and should be
rejected.
See https://github.com/tc39/proposal-temporal/pull/2397
Adds tests for ISO strings with unrecognized annotations, (i.e., neither
time zone nor calendar), in various combinations with recognized
annotations.
See https://github.com/tc39/proposal-temporal/pull/2397
Adds tests for ISO strings with calendar annotations, with and without the
critical flag, and also a check that the second calendar annotation is
disregarded, as per the IETF draft.
See https://github.com/tc39/proposal-temporal/pull/2397
Adds tests for ISO strings with named and numeric offset time zone
annotations, with and without the critical flag, with various combinations
of Z and offset in front of the annotation.
As of https://github.com/tc39/proposal-temporal/pull/2397 which reached
consensus in the August 2022 TC39 meeting, a date-time + Z with no bracket
annotation is no longer accepted as a relativeTo parameter; either the Z
should be removed or a bracket annotation should be added.
This requires adjusting a few existing tests, but doesn't require any new
ones.
See https://github.com/tc39/proposal-temporal/pull/2267 which eliminated
some unnecessary lookups of the calendar's dateAdd method from the
MoveRelativeDate AO, which is called in the calendar types' since() and
until() methods, Duration.p.round(), and Duration.p.total().
This adds tests for the order of all observable operations for these 10
methods, not just the lookups of dateAdd on the calendar. (These methods
needed to have their order of observable operations tested anyway.)
They heavily use the TemporalHelpers.calendarObserver and
TemporalHelpers.timeZoneObserver added in the previous commits.
https://github.com/tc39/proposal-temporal/pull/2267 included changes to
several code paths, not all of which are reachable through every method
tested here; only Duration.p.round() can trigger the full set.
https://github.com/tc39/proposal-temporal/pull/2267 reached consensus at
the July 2022 TC39 plenary meeting.
Similar to the previous commits with property bags and time zones, there
are also some existing tests that use a Proxy to test the order of
observable operations which involve user code
passed in as part of a Temporal.TimeZone object. I am going to write
several more tests that do this, as well. This seems like a good thing to
put into TemporalHelpers, where it can be implemented consistently so that
we don't get discrepancies in which operations are tracked, or bugs due to
a Symbol-valued property.
Updates existing tests to use this helper.
Similar to the previous commit with property bags, many existing tests use
a Proxy to test the order of observable operations which involve user code
passed in as part of a Temporal.TimeZone object. I am going to write
several more tests that do this, as well. This seems like a good thing to
put into TemporalHelpers, where it can be implemented consistently so that
we don't get discrepancies in which operations are tracked.
Updates existing tests to use this helper.
This adds tests for the normative change in tc39/proposal-temporal#2265,
which adds validation steps to certain abstract operations that call
Temporal.Calendar methods.
These had some duplication with some existing tests named
calendar-returns-infinity.js. Remove these, because the new tests are more
complete in testing what values are accepted.
The existing tests would fail after making the normative change from
tc39/proposal-temporal#2265 because they rely on the getter directly
returning whatever value the calendar method returned. This is no longer
the case, because the value returned by the calendar is validated, so
adjust the assertions in these tests.
Also, no longer any need to return a value from the calendar method that
needs to be converted; we'll add separate tests for that.
Expand these tests to cover all of the PlainDate, PlainDateTime,
PlainMonthDay, PlainYearMonth, and ZonedDateTime property getters that
delegate to the calendar methods.
Temporal tests written for the SpiderMonkey implementation. Mostly
covers edge cases around mathematical operations and regression tests
for reported spec bugs.
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
Some tests in staging used various IANA time zones in order to test DST
behaviour. Since implementations are technically not required to
understand IANA time zones, we have a fake DST time zone in
TemporalHelpers. Use that instead.
For a few cases where it's not practical to use the fake DST time zone
(because it only has one spring-forward and one fall-back transition, for
example), move a few tests into staging/Intl402/Temporal/.
See: #3649
As much as possible, remove non-ISO calendars and IANA time zones from the
Temporal tests in the staging folder.
In most cases, the non-ISO calendar can be replaced with the ISO calendar.
In other cases, create a custom calendar object with the appropriate
return value from toString(), and any other methods needed for that
particular test.
For time zones, in most cases the time zone can be replaced with UTC or a
constant offset time zone. Sometimes a custom time zone object with the
appropriate toString() is sufficient.
Move timezone-america-la.js to staging/Intl402/Temporal/ since its whole
point is to test an IANA time zone. Create a new tzdb-transitions.js in
staging/Intl402/Temporal to test behaviour of Temporal.TimeZone's
getPreviousTransition and getNextTransition for IANA time zones, since
UTC and constant offset time zones always return null for these methods.
There are still some cases where specific DST behaviour is tested. These
will be addressed in following commits.
See: #3649
Temporal tests written for the SpiderMonkey implementation. Mostly
covers edge cases around mathematical operations and regression tests
for reported spec bugs.
The "half___" modes all round to the nearest increment except when there
is a tie. The previous tests didn't test rounding in the case of any ties
(except for .toString()) so here we use some different numbers in which
there is a tie, in order to make tests where the "half___" modes are more
thoroughly tested.
See https://github.com/tc39/proposal-temporal/pull/2262 which added new
rounding modes from NumberFormat V3.
See https://github.com/tc39/proposal-temporal/pull/2262 which added new
rounding modes from NumberFormat V3.
These tests use the same format as the previous ones. The tests for the
"half" rounding modes aren't very good yet, as they don't show any of the
differences between the tiebreaking schemes; there aren't any ties in the
data to be broken. (Except in .toString().) A subsequent commit will
correct this.
Take all the existing tests for round() calculations using different
rounding modes and standardize them. Add tests for Duration, Instant and
ZonedDateTime, which were still in the old format in staging.
Take all the existing tests for since/until calculations using different
rounding modes and standardize them. Add tests for Instant and
ZonedDateTime, which were still in the old format in staging.
See https://github.com/tc39/proposal-temporal/pull/2262, which reached
consensus in the July 2022 TC39 meeting. This change added several
rounding modes from the NumberFormat V3 proposal, some of which were
listed as invalid in the roundingmode-invalid-string tests. Remove these
items from the list of invalid modes, since they are no longer invalid.
Many existing tests use a Proxy to test the order of observable operations
on a property bag argument that gets passed in to a Temporal API. I am
going to write several more tests that do this, as well. This seems like a
good thing to put into TemporalHelpers, where it can be implemented
consistently so that we don't get discrepancies in which operations are
tracked. (For example, we had some tests which didn't test for an ownKeys
operation that was supposed to be there.)
Updates existing tests to use this helper.
I've occasionally gotten bugs due to Get or Has operations being performed
on symbol-valued properties, and trying to format them inside backtick
strings, which throws. I've been meaning to consolidate this for a while
into a formatting function which nicely formats any kind of property key.
Now that I'm about to write more tests having to do with order of
observable operations, this seems like a good time to do it.
This is a refactor in temporalHelpers.js.
We did this inconsistently in PlainDate and ZonedDateTime, and not in the
other calendar-carrying types. Additionally, we don't have to create the
calendar explicitly in PlainDate.
Philip Chimento
Gokhan Kurt
Rick Waldron
André Bargull
Frank Yung-Fong Tang
Ms2ger
Mathias Bynens
Romulo Cintra
Shu-yu Guo