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.
Installation of ChakraCore by ESVU for some reason has been flaky for
quite a long time. Can't reproduce locally. This CI job doesn't add much
value by itself, so just remove it until some future time.
Closes: #3953
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>
