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.
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.
* Add Tests for ECMA402 PR811
Add tests to check the order of option readings and output
keys in resolvedOptions of Intl.NumberFormat and PluralRules.
* Address reveiw feedback
Hard code the list of property to be inspect for GetOption
Use compareArray
* Update test/intl402/NumberFormat/constructor-option-read-order.js
Co-authored-by: Richard Gibson <richard.gibson@gmail.com>
* Update test/intl402/NumberFormat/constructor-option-read-order.js
Co-authored-by: Richard Gibson <richard.gibson@gmail.com>
* Update test/intl402/NumberFormat/prototype/resolvedOptions/return-keys-order-default.js
Co-authored-by: Richard Gibson <richard.gibson@gmail.com>
* Update test/intl402/PluralRules/constructor-option-read-order.js
Co-authored-by: Richard Gibson <richard.gibson@gmail.com>
* Update test/intl402/PluralRules/constructor-option-read-order.js
Co-authored-by: Richard Gibson <richard.gibson@gmail.com>
* Fix intl402/PluralRules/prototype/resolvedOptions/return-keys-order-default.js
To test all options
* Add more tests
---------
Co-authored-by: Richard Gibson <richard.gibson@gmail.com>
Test the explicit setting of ignorePunctuation in the option bag
reflect to the value in resolvedOptions() under Thai and
other locales. (Thai is a special case)
Test the behavior of the compare sync with the value of
resolvedOptions().ignorePunctuation
Note the monkeypatch of getPossibleInstantsFor in test/built-ins/Temporal/
TimeZone/prototype/getInstantFor/argument-builtin-calendar-no-array-
iteration.js.
Other than that, all the tests are basically identical.
Adds new tests to order-of-operations.js in Duration.round and
Duration.total, to exercise the code path where previous to this normative
change, relativeTo would have been converted to PlainDate 3x and 2x,
respectively.
This shortcut path now exists in all round(), since(), and until()
operations.
In Instant, PlainDate, PlainDateTime, and PlainTime, the change isn't
observable, so no tests could be added. This adds test coverage for
- Duration.p.round()
- PlainYearMonth.p.since()
- PlainYearMonth.p.until()
- ZonedDateTime.p.round()
- ZonedDateTime.p.since()
- ZonedDateTime.p.until()
As well as a few cases where we are testing that certain calendar methods
get called during a round operation, but previously were doing so with
options that now become a no-op and no longer call those calendar methods.
In those cases, round to 2 ns, rather than 1 ns.
These two can be combined into one test, since they are very similar. This
will allow testing the sample DST time zone as well, which is not yet
tested.
The behavior of `/\p{RGI_Emoji}/v` and other properties of strings depends on the Unicode & Emoji version being used in the JavaScript engine. This patch adds tests verifying new additions to `RGI_Emoji` for each release of the Unicode Emoji standard are correctly matched.