Skip to content
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

Editorial: Fix next batch of editorial issues #3052

Merged
merged 15 commits into from
Dec 5, 2024
Merged

Editorial: Fix next batch of editorial issues #3052

merged 15 commits into from
Dec 5, 2024

Conversation

ptomato
Copy link
Collaborator

@ptomato ptomato commented Dec 5, 2024

This closes several issues spotted by @anba and @trflynn89, and also brings in the latest commits from test262.

Requires adding an expected failure, pending a test262 pull request.
Without custom calendars, it is no longer possible to give inputs to this
AO that would cause exceptions to be thrown. The two ISO Date-Time Records
must be within limits, so there is no way that the difference between them
could be anywhere near the Internal Duration Record limit.

h/t Anba

Closes: #3022
This is slightly simpler and easier to keep track of.

h/t Anba

See: #3022
…ethods

The difference between two other Temporal objects can't be so large that
it would cause TemporalDurationFromInternal to fail. So these operations
can't throw here.

h/t Anba

Closes: #3025
The input is an existing valid Temporal.Duration object, which cannot have
a total of days through nanoseconds that exceeds the 2⁵³ limit. So days
cannot be out of range in the CreateDateDurationRecord call.

h/t Anba

Closes: #3028
This only reduces the absolute value of roundedTimeDuration, so it's
impossible for it to go beyond the limit.

h/t Anba

Closes: #3030
The date duration is the difference between two ZonedDateTimes, so cannot
be anywhere near the limit. Therefore, it's impossible that adding 1 day
could take it over the limit.

h/t Anba

Closes: #3030
Quoting Anba: days is either zero or roundedWholeDays. When zero,
AdjustDateDurationRecord is trivially infallible. When roundedWholeDays,
it's also infallible, because roundedWholeDays is
truncate(DivideTimeDuration(roundedNorm, nsPerDay)) and roundedNorm is a
valid time duration.

Closes: #3033
dateDuration and roundedTimeDuration cannot have opposite signs, so the
operation can't throw.

dateDuration must have the same sign as duration, because dayDelta either
is 0 or also has the same sign as duration.

roundedTimeDuration must have the same sign as duration or be 0, because
either it is rounded from duration in step 10, or it is rounded from
beyondDaySpan in step 12.c. beyondDaySpan also cannot have the opposite
sign as duration if we go into the substeps of step 12.

See: #3023
dateDuration and remainder cannot have opposite signs, so the operation
can't throw.

dateDuration must either have the same sign as roundedTime or be 0,
because days must either be 0 or be equal to roundedWholeDays, which is
rounded from roundedTime.

remainder must either have the same sign as roundedTime or be 0, because
it is either equal to roundedTime or it has roundedWholeDays × HoursPerDay
subtracted from it. roundedWholeDays × HoursPerDay cannot be greater than
roundedTime because it is calculated from a truncating division of
roundedTime in step 6.

See: #3023
…nfallible

dateDifference and timeDuration cannot have opposite signs here, so the
operation can't fail. This is ensured by the loop above, which backs up
the intermediate date by one day until the signs match, which is asserted
after the loop exits in step 11.

See: #3023
We now have proven that all of the call sites cannot provide a date
duration and time duration with mixed signs. So we change the exception to
an assertion.

h/t Anba

Closes: #3023
This assertion was added in ce94055 but is not correct.
TemporalMonthDayString is not the last element passed in step 1 of
ParseTemporalCalendarString, but it is valid for the year to be absent
there.

I'm not exactly sure what I was going for with the assertion and I don't
think it's helpful to have it in hindsight even if it were correct.

Closes: #3045
Copy link

codecov bot commented Dec 5, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.73%. Comparing base (d42b24f) to head (fb6d1f9).
Report is 15 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3052      +/-   ##
==========================================
+ Coverage   95.71%   95.73%   +0.02%     
==========================================
  Files          21       21              
  Lines        9704     9705       +1     
  Branches     1742     1742              
==========================================
+ Hits         9288     9291       +3     
+ Misses        364      363       -1     
+ Partials       52       51       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Collaborator

@Ms2ger Ms2ger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@Ms2ger Ms2ger merged commit 728beeb into main Dec 5, 2024
10 checks passed
@Ms2ger Ms2ger deleted the editorial branch December 5, 2024 13:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants