These tests should cover the full functionality of the .groups object (and
the .indices.groups object, in the case of the /d flag) for RegExp.p.exec
and String.p.match:
- Matched DNCG has a result
- Unmatched DNCG is present and undefined
- DNCG matched in previous iteration but not in current iteration is
treated as unmatched
- Iteration order of properties corresponds with source order
See: #3704
Each named capturing group should count as its own parenthesized capturing
group, even if it has the same name as another group. So, some of these
expectations were missing `undefined` array elements for the variant of
the `x` capturing group that didn't match.
In the other expectations, we forgot to take into account that the
backreference is not inside a capturing group, so the group match should
not have doubled letters in it.
Parse-time syntax for RegExp literals is already tested. These two files
test runtime RegExp compilation, with respect to duplicate named capture
groups.
See: #3704
I discovered these tests had omitted some arguments to the PlainDateTime
constructor, leaving the calendar in the wrong position.
The tests were technically not incorrect, since the operation
ToIntegerThrowOnInfinity on the string "gregory" gives 0. But they could
spuriously pass if the implementation didn't do argument conversion
correctly, failed to throw on eraYear being ±Infinity, but subsequently
threw RangeError anyway because the calendars of the arguments didn't
match.
This tests the normative changes in
https://github.com/tc39/proposal-temporal/pull/2245, which achieved
consensus in the July 2022 TC39 meeting, specifically as they apply to the
Temporal.Calendar.prototype.mergeFields method.
Due to the use of the pre-existing spec operation CopyDataProperties, now
symbol keys are merged into the return value, and the order of observable
property operations has changed from a batch of [[GetOwnProperty]]
followed by a batch of [[Get]], to a series of interleaved
[[GetOwnProperty]]/[[Get]] pairs.
This tests some of the normative changes in
https://github.com/tc39/proposal-temporal/pull/2245, which achieved
consensus in the July 2022 TC39 meeting, specifically as they apply to
places where the MergeLargestUnitOperation was called.
Due to the use of the pre-existing spec operation CopyDataProperties, the
order of observable property operations has changed from a batch of
[[GetOwnProperty]] followed by a batch of [[Get]], to a series of
interleaved [[GetOwnProperty]]/[[Get]] pairs. This previously wasn't
tested because TemporalHelpers.propertyBagObserver didn't track
[[GetOwnProperty]] operations, but now it does.
Using assert.deepEqual was faulty here, since deepEqual doesn't take
symbol keys into account. This test wasn't actually testing that the
symbol keys were absent, and in fact passes if they are present.
(Rather than fixing deepEqual, since we hope to deprecate it as per
https://github.com/tc39/test262/issues/3476, add a custom assert function
in the test.)
Normally, a plain object passed into an API that takes a Temporal.TimeZone
has its 'timeZone' property checked (observably) with a Has operation
followed by a Get operation if the property is present. In the normative
change https://github.com/tc39/proposal-temporal/pull/2392 which reached
consensus at the September 2022 TC39 meeting, this was changed so that
this check is skipped for objects which have the Temporal.TimeZone
internal slots.
This adds tests to all entry points that pass a user-supplied object to
ToTemporalTimeZone, with a "poisoned" timeZone object which has the
correct internal slots but a 'timeZone' accessor property whose getter
throws. A correct implementation should not cause this getter to throw.
Normally, a plain object passed into an API that takes a Temporal.Calendar
has its 'calendar' property checked (observably) with a Has operation
followed by a Get operation if the property is present. In the normative
change https://github.com/tc39/proposal-temporal/pull/2392 which reached
consensus at the September 2022 TC39 meeting, this was changed so that
this check is skipped for objects which have the Temporal.Calendar
internal slots.
This adds tests to all entry points that pass a user-supplied object to
ToTemporalCalendar, with a "poisoned" calendar object which has the
correct internal slots but a 'calendar' accessor property whose getter
throws. A correct implementation should not cause this getter to throw.
In these tests, we should make a distinction in the name for clarity. It's
testing a time zone passed as a property in a property bag (either as an
argument, or as a relativeTo option), so name it accordingly as we do with
other tests in the same folder.
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
Mathias Bynens
Philip Chimento
Shu-yu Guo
Richard Gibson
Linus Groh
Nicolò Ribaudo
Gokhan Kurt
Rick Waldron
André Bargull