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.
The circleci/ images are deprecated and replaced by cimg/. Hopefully this
will have a glibc that is new enough for XS's versioned symbols to link
against.
Rename 'node_latest' to 'node_image' since the image is the LTS, not the
latest. The name would otherwise be confusing.
Closes: #3891
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.
This allows removing several tests, as calendar.dateAdd() is no longer
called in several places, and it's no longer possible to create a
situation where BigInt arithmetic is observable in NanosecondsToDays.