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.
Philip Chimento
Ioanna M Dimitriou H
Peter Hoddie
Linus Groh
Kevin Gibbons
Nicolò Ribaudo
SUZUKI Sosuke
Chengzhong Wu
Frank Yung-Fong Tang
André Bargull
Shu-yu Guo
Jordan Harband
Adam Shaw
Daniel Minor