Normative: Validate results of Calendar operations #2265
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov Report
@@ Coverage Diff @@
## main #2265 +/- ##
==========================================
- Coverage 95.03% 94.78% -0.26%
==========================================
Files 20 20
Lines 10881 10890 +9
Branches 1934 1925 -9
==========================================
- Hits 10341 10322 -19
- Misses 504 532 +28
Partials 36 36
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
ljharb
reviewed
Jun 9, 2022
Ms2ger
changed the title
ptomato
approved these changes
Jun 26, 2022
anba
force-pushed
the
validate-calendar-functions
branch
from
4f9ffba
to
7ed8abb
Compare
Moved into #2332. |
ptomato
added
spec-text
ptomato
added a commit
to ptomato/test262
that referenced
this pull request
Oct 4, 2022
The existing tests would fail after making the normative change from tc39/proposal-temporal#2265 because they rely on the getter directly returning whatever value the calendar method returned. This is no longer the case, because the value returned by the calendar is validated, so adjust the assertions in these tests. Also, no longer any need to return a value from the calendar method that needs to be converted; we'll add separate tests for that. Expand these tests to cover all of the PlainDate, PlainDateTime, PlainMonthDay, PlainYearMonth, and ZonedDateTime property getters that delegate to the calendar methods.
ptomato
added a commit
to ptomato/test262
that referenced
this pull request
Oct 4, 2022
This adds tests for the normative change in tc39/proposal-temporal#2265, which adds validation steps to certain abstract operations that call Temporal.Calendar methods. These had some duplication with some existing tests named calendar-returns-infinity.js. Remove these, because the new tests are more complete in testing what values are accepted.
ptomato
force-pushed
the
validate-calendar-functions
branch
from
389dc78
to
b6945af
Compare
ptomato
reviewed
Oct 4, 2022
|
This reached consensus in July 2022. I've rebased it and addressed my comment about 𝔽(), and added an implementation of the normative change to the reference code. Tests are in tc39/test262#3681, we'll need to update test262 once that's merged, since this invalidates some existing test262 tests. |
Ms2ger
pushed a commit
to tc39/test262
that referenced
this pull request
Oct 5, 2022
The existing tests would fail after making the normative change from tc39/proposal-temporal#2265 because they rely on the getter directly returning whatever value the calendar method returned. This is no longer the case, because the value returned by the calendar is validated, so adjust the assertions in these tests. Also, no longer any need to return a value from the calendar method that needs to be converted; we'll add separate tests for that. Expand these tests to cover all of the PlainDate, PlainDateTime, PlainMonthDay, PlainYearMonth, and ZonedDateTime property getters that delegate to the calendar methods.
Ms2ger
pushed a commit
to tc39/test262
that referenced
this pull request
Oct 5, 2022
This adds tests for the normative change in tc39/proposal-temporal#2265, which adds validation steps to certain abstract operations that call Temporal.Calendar methods. These had some duplication with some existing tests named calendar-returns-infinity.js. Remove these, because the new tests are more complete in testing what values are accepted.
The operation preamble already stated "[...] and validates the result.", but not actual validation took place.
`CalendarDaysInMonth` already calls `ToPositveInteger`.
The normative change in this PR changed the return types of these operations from "ECMAScript language value" to "integer", which means we need to convert them back to ECMAScript floats when exposing them to JS.
This adds structured headers to the abstract operations that call the calendar methods that back the Plain types' property getters. May as well do it while I was correcting the return types anyways.
This implements the changes from "Normative: Add missing validation to remaining Calendar operations", which adds a validation step to the abstract operations that call certain Temporal.Calendar methods.
These checks are all redundant due to ES.ToPositiveInteger() being called elsewhere in the same path.
ptomato
force-pushed
the
validate-calendar-functions
branch
from
b6945af
to
697e7bb
Compare
ptomato
force-pushed
the
validate-calendar-functions
branch
from
697e7bb
to
31de2c7
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The validation was already mentioned in the preamble of each operation, but it wasn't actually performed.