-
Notifications
You must be signed in to change notification settings - Fork 162
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update test262 #3072
Update test262 #3072
Conversation
Previously, getting any of the calendar properties in a non-ISO PlainDate representing the ISO date -271821-04-19 would trigger an exception because constructing a legacy Date for that date would fail. This adds a special case for this particular date, where we format 04-20 in a time zone that pushes the local time back to 04-19.
…endar Some leap months with 30 days don't occur until quite far in the past in the Chinese calendar. Instead of searching 100 years into the past each time, hardcode these cases, and only search 20 years into the past. (20 is chosen sort of arbitrarily, but several lunar calendars have cycles that are up to 19 years.)
The reference year algorithm in CalendarMonthDayToISOReferenceDate regarding the constraining of days exceeding the end of variable-length month, was implemented incorrectly in the reference code. For example, the intercalary month in the Ethiopian calendar may have 5 or 6 days. If we try to create a PlainMonthDay of M13-07, that should constrain to M13-06. But the first intercalary month counting back from the end of 1972 has 5 days, so M13-07 was erroneously constrained to M13-05. To solve this, maxLengthOfMonthCodeInAnyYear() to each helper. This is different from maximumMonthLength() which gives the month length for the given year, which may be an upper bound if the month length isn't easily determinable. Whereas, maxLengthOfMonthCodeInAnyYear() always gives the upper bound for that month over all years.
…Parts) The reference code was implemented incorrectly with regards to the order of operations prescribed by the spec text. ToNumber needs to be called on both non-Temporal-object arguments before checking whether they are the same type, and that check needs to occur before checking whether the date value is valid.
UTC is a common case. It never has offset transitions and its identifier does not need to be parsed. Adding these fast paths shaves considerable time off some test262 tests.
The one from es-abstract was showing up in profiles of some slow test262 tests, because it incorporates the assertions from ECMA-262, e.g. testing multiple times whether the arguments are integers. That is not necessary here, because we call it in a limited number of places and are guaranteed to call it with the correct arguments. Just delegate to String.prototype.padStart instead.
Some of the SpiderMonkey staging tests are incorrect. Others expose bugs in ICU4C.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3072 +/- ##
==========================================
+ Coverage 95.74% 96.21% +0.47%
==========================================
Files 21 21
Lines 9712 9867 +155
Branches 1741 1796 +55
==========================================
+ Hits 9299 9494 +195
+ Misses 362 323 -39
+ Partials 51 50 -1 ☔ View full report in Codecov by Sentry. |
let formatArgs = [a, b]; | ||
let formatter; | ||
if (isTemporalObject(a) || isTemporalObject(b)) { | ||
if (isTemporalObject(a) !== isTemporalObject(b)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Possible future refactor: isTemporalObject
could return the type of object rather than a boolean
Test262 recently imported a large body of tests from SpiderMonkey, including some Temporal tests. This PR pulls in the newest commit from test262.
Some of these new tests exposed bugs in the reference code in this repo, which I've fixed. Some of them ran slowly, which I've tried to speed up. A few exposed bugs in ICU or were incorrect by my reading of the spec, which I've added to the expected failures list and will follow up on later.