This contains tests for the normative PR
https://github.com/tc39/proposal-temporal/pull/2437, which is to be
presented for consensus to TC39 in the upcoming plenary meeting. That PR
changes the observable order of property accesses to be alphabetical where
possible.
1. String.prototype.toWellFormed's name is "toWellFormed".
2. "asserts" does not exist in the test harness, and "assert.throws"
expects the error type first.
This reconciles changes made in two normative PRs to the Temporal proposal
which each had their own separate PRs for tests. The yearOfWeek tests were
written before the changes to the ISO 8601 grammar which disallowed the
YYYY-MM-DD+UU format. This brings the yearOfWeek tests in line with the
tests for the other calendar methods.
This test template shared the same "path" as its sibling,
cls-decl-decorators-valid-syntax.template. That meant that these two
templates would race to generate the same test files with different
contents.
This prefixes the generated tests for class element decorators (as opposed
to class decorators) with "class-element-".
While we're at it, use assert() instead of assert.sameValue() for brevity,
if we are not specifically testing that the return value of hasOwnProperty
is the value true or false; and add more informative assertion messages to
help with debugging.
In some cases, the Object.hasOwnProperty.call could be replaced with
verifyProperty(), if the property descriptor was also being verified at
the same time.
This fixes some tests that were faulty to begin with: a common mistake was
Object.hasOwnProperty(obj, prop) which is probably going to return false
when that's not what you want.
The only instances left of `Object.hasOwnProperty` are one regression test
in implementation-contributed which I can't tell if it was intentionally
needed to trigger the regression, and a few instances of
`Object.hasOwnProperty('prototype')` which would defeat the purpose to
convert into `Object.prototype.hasOwnProperty.call(Object, 'prototype')`
form.
Closes: #3524
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.