This test should trip if an implementation forgets to perform the removals
that reached consensus in June 2024. (Although such an implementation
would technically comply with the specification, if you really need to do
that, please open an issue on the Temporal proposal repo rather than just
skiplisting this test.)
As in the previous commit, without custom calendars and time zones, some
functionality cannot be tested on implementations that don't have any
other calendars and time zones than iso8601 and UTC.
Some of the staging tests fall in this category. We take the opportunity
to port these into proper tests, in the intl402/ folder.
Previously getISOFields() was used to get the exact value of the
[[Calendar]] and [[TimeZone]] internal slots, as well as to get the
reference ISO year for PlainMonthDay and reference ISO day for
PlainYearMonth.
Use calendarId and timeZoneId for the former and toString() for the
latter.
It's no longer possible to fake built-in time zones using custom objects.
So testing DST shifts will have to use real built-in time zones. Replace
TemporalHelpers.springForwardFallBackTimeZone with America/Vancouver (it
was modelled on the DST transitions in 2000) and
TemporalHelpers.crossDateLineTimeZone with Pacific/Apia (it was modelled
on the 2011 switch to the other side of the international date line.)
These tests have to move to the intl402/ folder since non-Intl-aware
implementations are allowed (but not required) to support any built-in
time zones other than UTC.
In many cases we created a TimeZone or Calendar instance from a built-in
time zone or calendar. These tests can be trivially adapted to just use
the string ID.
Temporarily replace them with getISOFields().calendar/timeZone just to
keep the tests running until we remove Calendar and TimeZone objects
altogether.
See: tc39/proposal-temporal#2826
Following the upstream ECMA-402 change tested in the previous commit, add
test coverage for the corresponding functionality in Temporal. Fix one
test that was erroneous.
The module evaluation machinery has undergone non-trivial refactoring
since implementation. Sync up the comments and code for maintenance.
Notably,
- Actually use the kEvaluatingAsync status (previously conflated under
kEvaluated)
- [[IsAsyncEvaluating]] -> [[IsAsyncEvaluation]]
- GatherAsyncParentCompletions -> GatherAvailableAncestors
- async -> has_toplevel_await
- kAsyncModule -> kModuleWithTopLevelAwait
Bug: 347060515
Change-Id: Ia2c35d5b42ee9f58db841cdfcaef9d17b018c9c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5636701
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94591}
See tc39/proposal-temporal#2825. This is a mass removal of tests that use
this functionality, in a separate commit for ease of review. Further
adjustments will be made in the following commit.
This CL adds move() function and a getter for disposed to
DisposableStack prototype.
Bug: 42203506
Change-Id: I8d7750b1d4aa199ebeb997bde7fe6d06c9ccbff0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5528992
Commit-Queue: Rezvan Mahdavi Hezaveh <rezvan@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93931}
This should produce all the same results (except for a change to weeks
balancing in round(), which is now more consistent with since()/until())
but leads to different observable user code calls.
See https://github.com/tc39/proposal-temporal/issues/2742
and dispose method
This CL adds DisposableStack constructor, use() and dispose() methods
as developer exposed methods. Also, this CL fixed the use
of `using` keyword with `null` and `undefined` and adds tests for them.
Bug: 42203506
Change-Id: If50b9e33d9cbb3de2be41dc81e656d9d202b8fa8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5498999
Commit-Queue: Rezvan Mahdavi Hezaveh <rezvan@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93807}
Previously, this test checked for a particular format. This would break
depending on which engine executed it. Instead, test for the presence of
particular types and their values in the output of formatToParts().
(There's an existing comment which suggests that this should already have
been testing formatToParts().)
This CL adds `using` to bytecode generator. This CL does not include exception handling and JSDisposableStack methods.
Also, since `using` and `const` have the same behavior (except for disposing resources), we add required checks to the existing code.
Bug: v8:13559
Change-Id: I1d169859cc2a3e16c7cc9078219d5e4a466f4560
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5270855
Commit-Queue: Rezvan Mahdavi Hezaveh <rezvan@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93014}
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.
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.
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.
Reland https://crrev.com/c/4913993
This CL adds three tests from test methods tests to staging
directory with correct format.
Bug: v8:13556
Change-Id: I93817eb84e077436071dbae98bc800dd58851f91
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4983674
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Liviu Rau <liviurau@google.com>
Cr-Commit-Position: refs/heads/main@{#90645}
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.
There was one remaining Temporal test that was parsing an ISO string
with a sub-minute offset into a Temporal.TimeZone. A polyfill bug was
allowing this test case to pass, even though after
tc39/proposal-temporal#2607 it should have failed.
This commit removes the bad test case.
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.
These tests accompany a Temporal PR that works around a bug in
ICU 73.1 (which ships with Node 20). These test changes enable
tests to pass in both the buggy state and after the bug is eventually
fixed.
I wrote a similar test for Temporal.ZonedDateTime.p.toLocaleString, so
while this was fresh I decided to do the same for the other toLocaleString
calendar mismatch tests that were in staging.
In https://github.com/tc39/proposal-temporal/pull/2522 which reached
consensus at the March 2023 TC39 meeting, the functionality of
Temporal.ZonedDateTime.p.toLocaleString was changed substantially, to not
directly pass the ZonedDateTime to any Intl.DateTimeFormat methods. This
adds rewrites of all existing tests for toLocaleString, as well as a few
tests to verify that Intl.DateTimeFormat methods no longer support
Temporal.ZonedDateTime arguments.
As we are rewriting the tests anyway, this also ports all of the
Temporal.ZonedDateTime.p.toLocaleString tests that were in staging, to the
correct format for the main tree.
André Bargull
Philip Chimento
Shu-yu Guo
Luis Fernando Pardo Sixtos
test262-merge-bot
Rezvan Mahdavi Hezaveh
Adam Shaw
Igor Sheludko
Justin Grant
Liviu Rau