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>
Add tests to ensure that:
1. First `byteLength` isn't larger than `maxByteLength`.
2. Then `OrdinaryCreateFromConstructor` is called.
3. And finally `Create{Shared}ByteDataBlock` is called.
Time zone identifiers supported by ICU, but which aren't valid IANA
identifiers.
Implementations not supporting ECMA-402 are theoretically allowed to
support these identifiers, so the tests have to go into the "intl402"
directory.
This adds tests specifically for every kind of case that changes due to
the tweak to the date difference algorithm: differences from a longer
month to a shorter month, when the months are adjacent, in the same year
but not adjacent, and in different years.
Also adds tests for a case that does *not* change, but would trip on an
incorrectly implemented algorithm: when the intermediate months value
falls at the end of February.
There was incidental coverage of the change to the date difference
algorithm in other tests. Those are adjusted, as well.
Normative change: https://github.com/tc39/proposal-temporal/pull/2759
Consensus in February 2024
Adapts the tests that checked arbitrarily long loops, to now check that an
exception is thrown if the loop would happen.
Adds tests that exercise the newly added checks on return values of
getPossibleInstantsFor and getOffsetNanosecondsFor that limit UTC offset
shifts to 24 hours or less.
Also updates some step numbers in related tests.
The existing tests didn't cover some edge cases where implementations
have to compute the exact result of `numerator / denominator`, where at
least one of `numerator` and `denominator` can't be exactly represented
by an IEEE-754 double precision floating point value.
"precision-exact-mathematical-values-5.js" gets added in #3961, so the
new tests from this commit start at "precision-exact-mathematical-values-6.js".
NormalizedTimeDurationToDays can no longer loop indefinitely, because at
a certain point we will hit the upper bound of MAX_SAFE_INTEGER, so rename
the test to reflect that it can loop an arbitrary but limited number of
times.
Add a test for the RangeError condition in NormalizedTimeDurationToDays
when the time zone calculates a day length that is not a safe integer
number of nanoseconds.
While editing these tests, rename them to match the current name of the AO
and make sure the step numbers are up to date. (Normally I wouldn't care
so much about that, but these tests can be pretty confusing so it's good
to be able to refer to the spec text.)
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.
* Test closing async-from-sync iterator when resolving result promise abrupt completes.
These test new steps 6-6.a of AsyncFromSyncIteratorContinuation
as per normative changes of ecma626 PR 2600
https://github.com/tc39/ecma262/pull/2600
* Apply suggestions from code review
Co-authored-by: Kevin Gibbons <bakkot@gmail.com>
* Apply suggestions from code review
Co-authored-by: Nicolò Ribaudo <hello@nicr.dev>
* Refactoring tests to use the Async Helpers.
---------
Co-authored-by: Kevin Gibbons <bakkot@gmail.com>
Co-authored-by: Nicolò Ribaudo <hello@nicr.dev>
* Adjust existing tests to match new spec for async-from-sync iterators
Testing normative changes of ecma626 PR 2600
* Test that async-from-sync iterator closes when throw is undefined.
These test paths from newly added call to IteratorClose in step 7.c of
%AsyncFromSyncIteratorPrototype%.throw
as per normative changes of ecma626 PR 2600
* Apply suggestions from code review
Co-authored-by: Jordan Harband <ljharb@gmail.com>
* Refactoring tests to use the Async Helpers.
Addresses review comments
- https://github.com/tc39/test262/pull/3976/files#r1451071569
- https://github.com/tc39/test262/pull/3976/files#r1451075479
---------
Co-authored-by: Jordan Harband <ljharb@gmail.com>
* update constructor and toStringTag properties on Iterator.prototype
* includes cannot be empty for some reason
* update description
* add esid
* updates
* freeze Iterator.prototype
* don't try to use real GeneratorPrototype for these tests
Hosts are free to throw whatever error they want during module loading: there is no guarantee that the error thrown due to the import with `type: "foo"` is a SyntaxError.
* add tests for difference, intersection, symmetricDifference
* add tests for predicates
* more tests for ordering of calls
* fix copyrights
* add missed -0 test
* pass argument to methods, not just this
* assert methods return new objects
* typo in filename
* fix parens
* Update test/built-ins/Set/prototype/difference/add-not-called.js
Co-authored-by: Jordan Harband <ljharb@gmail.com>
* fix isSupersetOf/set-like-array.js
* add tests for negative zero with isDisjointFrom and isSupersetOf
* fix message in isSupersetOf/converts-negative-zero.js
* address comments from review
---------
Co-authored-by: Jordan Harband <ljharb@gmail.com>
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.
* Beginning of adding Set.prototype.union tests
* Fix description
* Add tests for GetSetRecord
Which also allows Set-like objects
* Add title to test descriptions
* Add test for ensuring values are appended
* Add tests for properties of union
Also: tests for RequireInternalSlot, Constructor, BuiltIns.
Added a test to ensure that -0F is converted to +0F
* Ensure Set.prototype.add is not called as part of .union
* fix lint issues
* Set subclassing and Symbol.species tests
* Set.prototype.union tests for arrays and subclass methods
* Add the Set-methods frontmatter feature flag
* Add additional Set.prototype.union test for edge cases
* Update test/built-ins/Set/GetSetRecord/keys-is-callable.js
Co-authored-by: Kevin Gibbons <bakkot@gmail.com>
* Use compareArray() for assertions
* Remove class field syntax
* Remove unused args
* Update test/built-ins/Set/prototype/union/subclass-receiver-methods.js
Co-authored-by: Jordan Harband <ljharb@gmail.com>
* Return original 'add'
* address comments
* add one more mutation in the evil mutating iterator test
* address further comments
---------
Co-authored-by: Kevin Gibbons <bakkot@gmail.com>
Co-authored-by: Jordan Harband <ljharb@gmail.com>
Co-authored-by: Ms2ger <Ms2ger@igalia.com>
In order to fixtc39/proposal-temporal#2563, we added invocations of
BalanceDurationRelative after some invocations of RoundDuration. These
cause observable calendar calls, which must be accounted for in some
existing tests.
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.
Unicode 15.1 added the following "simple" case-folding entries:
```
1FD3; S; 0390; # GREEK SMALL LETTER IOTA WITH DIALYTIKA AND OXIA
1FE3; S; 03B0; # GREEK SMALL LETTER UPSILON WITH DIALYTIKA AND OXIA
FB05; S; FB06; # LATIN SMALL LIGATURE LONG S T
```
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}
These tests were incorrect, in checking for a RangeError when only one of
the era/eraYear fields were given. From CalendarResolveFields:
"The operation throws a *TypeError* exception if the properties of
_fields_ are internally inconsistent within the calendar or insufficient
to identify a unique instance of _type_ in the calendar."
Built-in non-ISO calendars require either monthCode/day, or month/day plus
some form of year specification.
This adds test coverage for each of the categories listed in
https://github.com/tc39/proposal-temporal/issues/2664, of which some must
currently reside in the test/intl402/ folders.
We'll do this for now, then separately work on migrating all of the tests
that require a non-ISO8601 calendar but aren't dependent on it being any
particular calendar.
In the AO DisambiguatePossibleInstants, a PlainDateTime instance is passed
to user code. This instance should have the built-in ISO 8601 calendar.
Here are some tests that ensure it does.
See tc39/proposal-temporal#2671.
In PlainYearMonth arithmetic, we need to find the end of the month when
adding a negative duration or subtracting a positive one. This end of the
month can be out of range.
Test case based on one provided by Anba. See issue:
https://github.com/tc39/proposal-temporal/issues/2700
Two issues:
1. There was a typo, the first `gen` should have been `genFn`.
2. And the last `toString` result should be `'[object Generator]'`,
because `Object.getPrototypeOf(gen) == genFn.prototype`. And the
`@@toStringTag` property of `genFn.prototype` is inherited from
`Generator.prototype[@@toStringTag]`.
That also means the "iterator-helpers" flag isn't needed for this test.
For the statement level test, the inner class name is not initialized
at the time the decorators evaluate, resulting in a ReferenceError
that the declaration can not be accessed prior to initialization.
Similar, non-decorator code, like:
class C {
static dec() {}
static {
this.x = C.dec();
class C {}
}
}
also results in a ReferenceError.
For the expression level test, the var C is undefined at the time the
decorators are evaluated, resulting in TypeError while trying to access
a member of undefined.
Similar, non-decorator code, like:
var C = class {
static f() {};
static {
this.x = C.f();
}
}
also results in a TypeError.
This removes several loopholes where it was possible to return particular
values from user calls that would cause infinite loops, or calculate
zero-length days.