* Import relevant files from #3888
* Removing parts in resizableArrayBufferUtils.js and adding it in includes,
while applying review changes from PRs for previously tested methods.
* Removes forgotten ArrayJoinHelper
* Import relevant files from #3888
* Removing parts in resizableArrayBufferUtils.js and adding it in includes,
while applying review changes from PRs for previously tested methods.
* Restructures ArrayIndexOfNumOrBigInt to use MayNeedBigInt as it seems clearer.
* Adds missing test file for Array.prototype.indexOf
This CL adds subtypes (SyncJSDisposableStack and AsyncDisposableStack)
to JSDisposableStack as well as `await using` to the bytecode generator.
Currently async generators are broken and the fix is left as a TODO
in this CL. Also, exception handling (promise rejections) will be
completed in a follow up CL.
Bug: 42203814
Change-Id: I303a380b57fb4ab4662e4f55fb4dc9b14d18cd2a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5569647
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Rezvan Mahdavi Hezaveh <rezvan@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94944}
Temporal doesn't specify concrete era names, so tests shouldn't assert
for example that the era code of the current Gregorian era is `"ce"`. We
still want to validate the era names somehow however, so allow alternative
era names using the era codes from the "Intl era and monthCode" proposal.
* Import relevant files from #3888
* Removing parts in resizableArrayBufferUtils.js and adding it in includes,
while adjusting usage of CollectValuesAndResize and applying review changes
from PRs for previously tested methods.
* Added missing 'shrink' tests for Array.prototype.forEach and removed forgotten lines
Also renames ResizeBufferMidIteration to ResizeMidIteration
* Forgotten by copy paste
Now that we don't have to deal with strings or objects as input to the
calendar ID or time zone ID parameter of constructors, we accept only the
data that actually goes into the internal slots.
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.
Without custom calendars and time zones there are actually a bunch of
things that we now can't test on implementations that don't have non-ISO
calendars or non-UTC time zones. (Alternatively, we can say that these are
functionalities that those implementations don't have to implement.)
These are no longer possible without custom objects. Also add an exception
for calendar and timeZone properties in property bag observers so they are
not treated as objects.
Many tests tested some functionality while asserting that there were no
calls of calendar or time zone methods. We can continue testing the
functionality, but there are no more methods to call, so we can delete
those parts of the tests.
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.
Some of the tests can be removed altogether since they deal with what
forms of input can be passed to ToTemporalTimeZoneSlotValue. Those are
tested on every method that takes a TimeZone as input.
Other tests are still relevant, but need to move to ZonedDateTime.p.equals
where the various quirks of time zone equality can still be tested. (Some
of these still will be removed in a following commit because they use
time zone objects.)
See: #2826
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
* Import relevant files from #3888
* Removing parts in resizableArrayBufferUtils.js and adding it in includes,
while adjusting usage of CollectValuesAndResize and applying review changes
from PRs for previously tested methods.
* Import relevant files from #3888
* Removing parts in resizableArrayBufferUtils.js and adding it in includes,
while adjusting usage of CollectValuesAndResize and applying review changes
from PRs for previously tested methods.
* Import relevant files from #3888
* Removing parts in resizableArrayBufferUtils.js and adding it in includes,
while adjusting usage of CollectValuesAndResize and applying review changes
from PRs for previously tested methods.
* Import relevant files from #3888
* Removing parts in resizableArrayBufferUtils.js and adding it in includes,
while adjusting usage of CollectValuesAndResize and applying review changes
from PRs for previously tested methods.
magic-akari
Jordan Harband
Marko Lahma
Ioanna M Dimitriou H
Ioanna M. Dimitriou H
Frank Yung-Fong Tang
Shu-yu Guo
Chengzhong Wu
André Bargull
Rezvan Mahdavi Hezaveh
Kevin Gibbons
Meghan Denny
Philip Chimento