As per the discussion in
https://github.com/tc39/proposal-temporal/issues/2379#issuecomment-1248557100
and the PR https://github.com/tc39/proposal-temporal/pull/2398, which is
to be presented for consensus to TC39 in the upcoming plenary meeting, UTC
offsets and the Z designator should be disallowed after any date-only
strings (YYYY-MM-DD, YYYY-MM, and MM-DD). They should only be allowed to
follow a time component. Z remains disallowed in any string being parsed
into a Plain type.
Annotations become allowed after any ISO string, even YYYY-MM and MM-DD
where they were previously disallowed.
To be presented for consensus in the November/December TC39 meeting. This
adds tests for a 'yearOfWeek' getter to PlainDate, PlainDateTime, and
ZonedDateTime, for use alongside 'weekOfYear', and tests for a
corresponding method to Calendar.
The tests are basically the existing tests of 'weekOfYear' adapted.
Temporal issue: https://github.com/tc39/proposal-temporal/issues/2405
This contains tests for the normative PR
https://github.com/tc39/proposal-temporal/pull/2433, which is to be
presented for consensus to TC39 in the upcoming plenary meeting. That PR
changes ToTemporalCalendar to throw when it encounters a Temporal.TimeZone
instance, and ToTemporalTimeZone to throw when it encounters a
Temporal.Calendar instance.
The Python 2 and 3 jobs run essentially the same thing twice. I asked for
a sign from implementations if any of them were relying on Python 2 for
their test262 runners, but didn't hear of any that were.
The Python tools are changed so rarely that I think it's OK to drop this
CI job. If a future change breaks Python 2 for someone, we can accept PRs
to fix it on a best-effort basis, or reinstate this CI job if it's really
necessary.
Closes: #3480
Co-authored-by: Richard Gibson <richard.gibson@gmail.com>
Co-authored-by: Ms2ger <Ms2ger@gmail.com>
We already have a similar test covering TimeZone.id that ensures toString
is not called. We did not have this coverage yet for Calendar.id, so adapt
the TimeZone test for Calendar.
This adds order-of-operations tests that cover all of the Temporal entry
points that accept options bags, that were not already covered. We'll be
using these tests in the future to verify
https://github.com/tc39/proposal-temporal/issues/2254
However, the tests in this commit reflect the current state of the
proposal, not the potential normative change.
Some of the existing order-of-operations tests didn't observe the calendar
operations. Add a TemporalHelpers.calendarObserver() calendar to the
invocations of these methods in the order-of-operations tests.
Some of the existing order-of-operations tests didn't pass an options bag:
primarily from(), with(), add() and subtract(). (since() and until() were
covered in a previous commit.)
Add a TemporalHelpers.propertyBagObserver() options bag to the invocations
of these methods in the order-of-operations tests.
The Temporal.Calendar.prototype.daysInMonth() method is observably called
in a few places in the spec. It should be tracked on the object returned
from TemporalHelpers.calendarObserver().
The `relativeTo` parameter in an options bag may be undefined, a PlainDate
instance, or a ZonedDateTime instance. Each of these three possibilities
causes a different set of observable operations, which we can test in our
existing order-of-operations tests.
There are additional observable operations that occur when providing an
`offset` property in a relativeTo or ZonedDateTime property bag. We can
test these in our existing order-of-operations tests.
%TypedArray%.prototype.map's iteration count does not change even though the source view is resized during the iteration.
And since result is just returning index, then result array should be [0, 1, 2].
Use the new collections of strings in TemporalHelpers.ISO to add more
tests for ISO strings in API entry points that convert an ISO string to
Temporal.PlainYearMonth or Temporal.PlainMonthDay.
The idea is to deduplicate more string tests into methods on this object,
that return collections of valid and invalid strings. This adds
collections of valid and invalid PlainYearMonth and PlainMonthDay strings.
Adds a test similar to the one in #3697, but in the main tree.
The six code points in this test have an "F" for full case mapping in
CaseFolding.txt, and so they should not be considered in the
Canonicalize operation.
Current versions of SpiderMonkey and V8 fail this test, others pass.
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.
snek
Philip Chimento
André Bargull
Doehyun Baek
Yusuke Suzuki
Ms2ger
Mathias Bynens
Rick Waldron
Timothy Flynn
Shu-yu Guo
Richard Gibson