Audit of user code calls, part 1 #2645
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
This was referenced Aug 11, 2023
Codecov Report
@@ Coverage Diff @@
## main #2645 +/- ##
==========================================
- Coverage 96.06% 96.04% -0.03%
==========================================
Files 20 20
Lines 11594 11584 -10
Branches 2192 2195 +3
==========================================
- Hits 11138 11126 -12
- Misses 393 395 +2
Partials 63 63
|
justingrant
reviewed
Aug 14, 2023
justingrant
approved these changes
Aug 14, 2023
Ms2ger
approved these changes
Aug 16, 2023
If we convert an exact time into a PlainDateTime, we're already calculating the time zone's UTC offset for that exact time. In the case where we need the UTC offset for another purpose in the same method, we should not call the time zone method again to recalculate it. Instead, we call the getOffsetNanosecondsFor method once, and pass the result to the GetPlainDateTimeFor abstract operation. This affects the following methods, removing an observable property Get and observable Call to getOffsetNanosecondsFor: - Temporal.Instant.prototype.toString - Temporal.ZonedDateTime.prototype.toString - Temporal.ZonedDateTime.prototype.round - Temporal.ZonedDateTime.prototype.getISOFields
Time units are no longer included in the array passed as the argument of Calendar.p.fields(). (And as long as we're doing this, we may as well limit fields() so that it doesn't accept time units. They are never used.) This doesn't eliminate any user-visible calls by itself, but is a prerequisite for eliminating the visible Gets of time unit properties on the receiver of PlainDateTime.p.with() and ZonedDateTime.p.with().
In PlainDateTime.p.with() and ZonedDateTime.p.with(), avoid calling the property getters to obtain the values for the time units, since they do not need to go through the calendar; we can unobservably get the same values from the receiver's internal slots. In ZonedDateTime.p.with(), additionally we don't need to call the getter for the `offset` property. Since we have the offset nanoseconds already, we can do what the getter does and format an offset string with FormatTimeZoneOffsetString.
…with() Instead of calling PrepareTemporalFields on the receiver in ZonedDateTime.p.with() to get the values of the date units, first create a PlainDateTime from the ZonedDateTime's exact time and time zone, and call PrepareTemporalFields on that. This still calls the corresponding calendar method for each field, but avoids calling the time zone's getOffsetNanosecondsFor() method redundantly for each field.
Following the precedent set in #2447, if we're going to pass the options object to a calendar method we should make a copy of it. Also flatten the 'options' property once it's read and converted to a string in InterpretTemporalDateTimeFields, so that it doesn't have to be observably converted to a string again in Calendar.p.dateFromFields(). In PlainDateTime.from, delay validation of the options until after validation of the ISO string, for consistency with ZonedDateTime.from and in accordance with our general principle of validating arguments in order. This affects the following APIs, which are all callers of InterpretTemporalDateTimeFields: - Temporal.PlainDateTime.from() - Temporal.PlainDateTime.prototype.with() - Temporal.ZonedDateTime.from() - Temporal.ZonedDateTime.prototype.with() It does not affect ToRelativeTemporalObject, even though that also calls InterpretTemporalDateTimeFields, because it does not take an options object from userland.
…m,p.with} Also following the precedent set in #2447, this preserves consistency with analogous from/with operations in {Plain,Zoned}DateTime that need to read the overflow option twice in order to deal with time and date units separately.
ptomato
force-pushed
the
user-code-calls-part-1
branch
from
dc7a33b to
bef16c9
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.
#2519 is a large pull request that touches everything, and it's difficult to keep rebasing it while I work on the test coverage. I'd like to split it into parts, instead, and land each part as soon as the test coverage is ready. This first part consists of commits that already have complete test coverage, in tc39/test262#3894.
These commits have already been reviewed in #2519. The only change aside from rebasing them was to address Richard's comment about the order in which ToTemporalOverflow is called in the "Normative: Copy options object..." commits.