-
-
Notifications
You must be signed in to change notification settings - Fork 411
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
Migrate Temporal
to its own crate.
#3461
Conversation
Test262 conformance changes
|
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #3461 +/- ##
==========================================
+ Coverage 44.59% 45.11% +0.52%
==========================================
Files 487 496 +9
Lines 50601 50610 +9
==========================================
+ Hits 22563 22833 +270
+ Misses 28038 27777 -261 ☔ View full report in Codecov by Sentry. |
b202355
to
87f86eb
Compare
Temporal
to its own crate.
Marking this as ready for review as I think this is probably a good starting point to continue from for the crate. General thoughts:
|
568206d
to
ac545bf
Compare
I think it would be good to discuss with the whole team if we want to separate this crate from Boa or not, so I'll add it to tomorrow's discussion topics. |
ac545bf
to
c251927
Compare
Agreed 😄 I just wanted the branch to be up to date and ready if the decision was to move forward with it. |
c251927
to
08d8e02
Compare
@raskad @HalidOdat will try to review this in the next few days. |
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.
Great work on this @nekevss!
There are some small things like docs, and the like but, we can leave those for future PRs :)
@jedel1043 I think Github will not let us merge this until you have approved the PR because you requested changes. |
#[derive(Debug, Clone)] | ||
pub struct TemporalError { | ||
kind: ErrorKind, | ||
msg: Box<str>, | ||
} |
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.
Note for the future: Since Temporal
overall has pretty specific errors, I think it would be good to check if we could avoid allocations and just return a plain:
enum TemporalError {
Error1(Error1),
Error2(Error2),
Error3(Error3)
}
And offer a TemporalError::get_ecma_error_type -> ErrorKind
method.
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.
That could be a good optimization to look into.
boa_temporal/src/fields.rs
Outdated
} | ||
} | ||
|
||
fn month_code_to_integer(mc: TinyStr4) -> TemporalResult<i32> { |
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.
Could probably use TinyAsciiStr<4>
instead, since this type has an ominous warning:
These are temporary compatability reexports that will be removed in a future version.
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.
Overall a really needed crateization! Just have a concern about the "context" feature, but after that's solved we can merge.
boa_temporal/src/date.rs
Outdated
/// | ||
/// Temporal Equivalent: 3.5.13 `AddDate ( calendar, plainDate, duration [ , options [ , dateAdd ] ] )` | ||
#[inline] | ||
#[cfg(feature = "context")] |
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.
I don't think adding a feature that gates a parameter is the greatest idea. If two separate crates import boa_temporal
but one of them uses the context
feature and the other doesn't, it would break the build for the one that doesn't (cargo unifies features). A better idea would be to remove the feature and add a contextual_add_to_date
method that has the optional parameter, and add_to_date
shouldn't take any context
parameter.
Yeah, I have a comment that definitely should be resolved before merging this. |
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.
Nice work!
This is the initial rough draft on separating
Temporal
into an engine agnostic crate. There's a lot in this branch approach-wise that I think is an improvement on the current implementation, and at the very least we may be able to work in to the current implementation in smaller pieces.The biggest point of concern that is a potential blocker for this PR is the safety involving custom user calendars implementation (CustomRuntimeCalendar
inboa_engine/src/builtins/temporal/calendar/object.rs
). Currently, the implementation hasCustomRuntimeCalendar
hold a*mut Context
to provide access to Boa's context when the user calendar is called by the temporal library.Edit:
@jedel1043's suggestion of using
&mut dyn Any
and downcasting seems to work, so I'll work on cleaning this up and getting this in a more mergeable state! 😄Feel free to leave any feedback whenever!
Also, as this is a more agnostic library, should we continue with the crate continue with the naming approach of the other crates (e.g.
boa_temporal
) or should the name be more of a generic name (e.g.temporal_rs
).Edit 2: Linking #1804 to this PR