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. |
|
@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.
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.
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.
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.
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.
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. |
This is the initial rough draft on separating
Temporalinto 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 (CustomRuntimeCalendarinboa_engine/src/builtins/temporal/calendar/object.rs). Currently, the implementation hasCustomRuntimeCalendarhold a*mut Contextto provide access to Boa's context when the user calendar is called by the temporal library.Edit:
@jedel1043's suggestion of using
&mut dyn Anyand 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