* 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.
* Apply suggestions from code review
* 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.
* Added missing 'shrink' test for Array.prototype.reduceRight
* Import relevant files from #3888
* Adds resizableArrayBufferUtils.js to includes and removes its content
from each test. Also splits tests for .byteLength and .byteOffset to
new files in the respective directories.
Test lines calling .buffer in .../length/resizable-buffer-assorted.js
were not split to .../buffer/ as they seem to only do a check for the
test on .length but perhaps they need to be also split to a new file
.../buffer/resizable-buffer-assorted.js
* 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.
* Some changes for readability.
* 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 redundant documentation
* Address review comments.
* 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.
* 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.
* Addresses review comment removing forgoten onlyStrict flag
a62d978ca6 (r1663298683)
This PR proposes changes to existing test262 tests to allow them to pass under Hardened JavaScript (see Secure ECMAScript proposal and Hardened JavaScript). Moddable uses Hardened JavaScript for JavaScript runtimes on resource constrained embedded devices, including those targeted by ECMA-419.
The changes fall into four groups:
1. Replace use of new Date() with new Date(1970). Scripts running inside a Compartment cannot retrieve the current time, so new Date() throws but new Date(1970) succeeds. Very few tests need the current time, but instead simply need a Date instance.
2. Use Object.defineProperty instead of setting existing built-in properties directly, such as toString and toValue. In Hardened JavaScript, prototypes of built-in objects are frozen. Consequently, setting properties of an instance that exist on the prototype throw (Hardened JavaScript is always in strict mode).
3. Eliminate use of Math.random(). Scripts running inside a Compartment cannot generate random numbers. One test identified so far uses Math.random() in a way that can easily be replaced with a counter.
4. Narrow the scope of exception tests. Consider the following
assert.throws(TypeError, () => {
var s1 = new Date();
s1.toString = Boolean.prototype.toString;
s1.toString();
});
This test passes, but only because new Date() fails by throwing a TypeError. If the invocation of the Date constructor is resolved by (1) above, then the assignment to toString fails as per (2) above. The script should be modified as below to ensure that assert.throws only tests the intended statement, s1.toString(). The modified script tests the intended functionality and passes under Hardened JavaScript
var s1 = new Date(1970);
Object.defineProperty(s1, "toString", {
value: Boolean.prototype.toString
});
assert.throws(TypeError, () => {
s1.toString();
});
This is an initial PR to begin the process of adapting test262 for use with Hardened JavaScript. Further changes are expected, with the vast majority likely to fall into the four groups described above.
Thank you to gibson042, kriskowal, and erights for their advice on this work.
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.
There is no such hidden constructor, it's the same as the hidden
AsyncFunction constructor. In other words:
```js
Object.getPrototypeOf(async () => {}).constructor ===
Object.getPrototypeOf(async function () {}).constructor
```
Also add a test to ensure that %AsyncFunction.prototype% is indeed the
prototype of an async arrow function.
Closes#4044.
* RAB: Integrate staging tests for the .every method
of Array.prototype and TypedArray.prototype
This is part of PR #3888 to make reviewing easier.
Includes changes to use the helper ./harness/resizableArrayBufferUtils.js
* Added missing includes
* Removed unnecessary function call.
* Apply suggestions from code review
* Applied review suggestion to the rest of the files
* Addressed forgotten review comment noting some files are missing.
https://github.com/tc39/test262/pull/4074#pullrequestreview-2046589557
Adds forgotten tests from #3888
* Addresses review comment.
* Fixed forgotten rename
* Simplify the tests and add documentation.
New approach replaces ...Helper with CollectResize to make the tests easier to understand.
In particular:
- Replaced the need for '...Helper' abstractions with a more descriptive
function 'ResizeBufferMidIteration', which the .every method can call
directly.
- Moved 'let values' back outside of the loops, together with a function
definition 'ResizeBufferMidIteration' to persist the side effects that
'CollectValuesAndResize' has on 'values' but without having to define
this inside every loop.
+ So this reverts commit d9a2bac41f87f0964a43d34c6f349b6d78401633 and
+ this reverts commit 0bc2d66335671cac56912981b73c7900bf309cee.
- Added documentation.
* Documentation style change and remove accidental additions.
* Test that `nfOptions.roundingMode` for seconds / microseconds / nanoseconds is `"trunc"`
* Add license header
* Use `Intl.NumberFormat` instead of `testintl.js` harness
* Use correct harness
RAB: Integrate staging tests for the .fill method
of Array.prototype and TypedArray.prototype
This is part of PR #3888 to make reviewing easier.
Includes changes to use the helper ./harness/resizableArrayBufferUtils.js
RAB: Integrate staging tests for the .entries method
of Array.prototype and TypedArray.prototype
This is part of PR #3888 to make reviewing easier.
Includes changes to use the helper ./harness/resizableArrayBufferUtils.js
RAB: Integrate staging tests for .copyWithin method
of Array.prototype and TypedArray.prototype
This is part of PR #3888 to make reviewing easier.
Includes changes to use the helper ./harness/resizableArrayBufferUtils.js
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.
Various edits to existing tests so that they make more sense with the
removal of relativeTo.
New tests specifically testing that calendar units cannot be added or
subtracted directly.
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 covers an edge case that we hit, where 24 hours would not balance up
to one day in a 25-hour day if only largestUnit was specified, but would
erroneously balance up if rounding was also performed by specifying
smallestUnit.
In ZonedDateTime.p.since/until, it's possible for AddDateTime to hit the
limit if the rounding increment is very high, even if the resulting
rounded duration isn't outside of the limit. Add a test covering this
case.
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}
* RAB: Integrate staging tests for .byteLength method
of TypedArray.prototype
This is part of PR #3888 to make reviewing easier.
Includes changes to use the helper ./harness/resizableArrayBufferUtils.js
* RAB: Integrate staging tests for .at method
of Array.prototype and TypedArray.prototype
This is part of PR #3888 to make reviewing easier.
Includes changes to use the helper ./harness/resizableArrayBufferUtils.js
Numeric "minute" and "seconds" units now default to "always" display, so we have
to add an additional test to cover when "auto" display is used. Additionally add
more inputs to cover all possible test combinations.
* Update test for o[p] = f()
Update S11.13.1_A7_T3.js now that consensus has been reached on https://github.com/tc39/ecma262/pull/3307.
* Rename test and add an analogous one for super.
* test formatting when microseconds or nanoseconds are the first numeric-styled unit
* incorporated Philip Chimento guidance re: padding fractional components
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().)
For each Temporal type, add a test (which should not be sensitive to the
exact locale format) that ensures dateStyle affects the output, for a
Gregorian and non-Gregorian calendar.
See https://github.com/tc39/proposal-temporal/issues/2058
It was previously not tested what options value a custom calendar's
dateFromFields() method would be called with, when called from the
toPlainDate() method of PlainYearMonth/PlainMonthDay.
See tc39/proposal-temporal#2803
These tests were supposed to test an invalid ISO string being used as the
`calendar` property in a property bag. Instead they were testing being
used as an invalid ISO string directly where a PlainDate input was needed.
(That is also already covered elsewhere.)
Due to overlooked copy-paste errors we were creating the wrong type of
instance in these tests, and therefore testing the wrong method.
(Add blank line for consistency with the other instances of these tests.)
After rounding relative to a ZonedDateTime, we have to potentially adjust
for DST. With a time zone providing nonsensical values, the duration may
go out of range.
See: tc39/proposal-temporal#2801
This test isn't testing what the assertion message previously said it was
testing. The integer is allowed to be unsafe, but in this case its
float64-representation is out of range.
See: https://github.com/tc39/proposal-temporal/issues/2785
With test cases kindly provided by Anba, this adds test coverage for the
abrupt completion in the last step of DifferenceTemporalPlainDateTime,
where the resulting Duration components have mixed signs.
See: https://github.com/tc39/proposal-temporal/issues/2783
normalized-time-duration-to-days-range-errors.js tests for several error
cases in the AO NormalizedTimeDurationToDays. Adding assertion messages
helps to know which one you are debugging.
As per IETF, annotation keys may only consist of lowercase letters,
dashes, and digits, and an optional leading underscore. Uppercase letters
are non-syntactical. Add tests covering this.
These test cases ensure that DST disambiguation does not take place on
intermediate values that are not the start or the end of the calculation.
Note that NormalizedTimeDurationToDays is no longer called inside
Temporal.Duration.prototype.add/subtract, so a few tests can be deleted.
Other tests need to be adjusted because NormalizedTimeDurationToDays is
no longer called inside Temporal.ZonedDateTime.prototype.since/until via
DifferenceZonedDateTime, although it is still called as part of rounding.
In addition, new tests for the now-fixed edge case are added, and for the
day corrections that can happen to intermediates.
See https://github.com/tc39/proposal-temporal/pull/2760
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}
The tests are passing an explicit `hour12` option, which disables any
`hourCycle` option and any `u-hc` Unicode extension. Therefore passing
input locales with `u-hc` is invalid.
```js
let locale = "en-u-hc-h24";
let hcDefault = new Intl.DateTimeFormat(locale, { hour: "numeric" }).resolvedOptions().hourCycle;
assert.sameValue(hcDefault, "h24", "hour-cycle through Unicode extension");
let hc24 = new Intl.DateTimeFormat(locale, { hour: "numeric", hour12: false }).resolvedOptions().hourCycle;
// Incorrect assertion, because |hc24| uses |hour12|, which disables any
// hour-cycle option and the hour-cycle is determined from the locale "en".
// That means |hc24| will be "h23".
assert.sameValue(hc24, hcDefault);
```
Based on PR #3807 which had generated these tests from templates,
but was stuck due to issue #3808.
Co-Authored-By: Guillaume Emont <guijemont@igalia.com>
Co-Authored-By: Ioanna M. Dimitriou H <idimitriou@igalia.com>
Ron Buckton
Ioanna M. Dimitriou H
Philip Chimento
Ioanna M Dimitriou H
André Bargull
Frank Tang
Timothy Flynn
Leo Balter
Sosuke Suzuki
magic-akari
Marko Lahma
Shu-yu Guo
Chengzhong Wu
Rezvan Mahdavi Hezaveh
Kevin Gibbons
Peter Hoddie
Linus Groh
Nicolò Ribaudo
Chengzhong Wu
Adam Shaw
Luis Fernando Pardo Sixtos
Timothy Leverett
test262-merge-bot
Jordan Harband
Ben Allen
Ross Kirsling
Mathias Bynens
Sosuke Suzuki
Ross Kirsling
Philip Chimento
Guillaume Emont
Cam Tenny
Aditi