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

Migrate Temporal to its own crate. #3461

Merged
merged 9 commits into from
Dec 4, 2023
Merged

Conversation

nekevss
Copy link
Member

@nekevss nekevss commented Nov 11, 2023

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 in boa_engine/src/builtins/temporal/calendar/object.rs). Currently, the implementation has CustomRuntimeCalendar 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

Copy link

github-actions bot commented Nov 11, 2023

Test262 conformance changes

Test result main count PR count difference
Total 95,609 95,609 0
Passed 76,526 76,526 0
Ignored 18,132 18,132 0
Failed 951 951 0
Panics 0 0 0
Conformance 80.04% 80.04% 0.00%

Copy link

codecov bot commented Nov 11, 2023

Codecov Report

Attention: 1429 lines in your changes are missing coverage. Please review.

Comparison is base (a8aad0b) 44.59% compared to head (1b2ae98) 45.11%.
Report is 12 commits behind head on main.

Files Patch % Lines
...oa_engine/src/builtins/temporal/calendar/object.rs 16.57% 292 Missing ⚠️
boa_temporal/src/fields.rs 0.00% 237 Missing ⚠️
boa_engine/src/builtins/temporal/calendar/mod.rs 29.08% 139 Missing ⚠️
boa_temporal/src/options.rs 0.00% 138 Missing ⚠️
boa_temporal/src/calendar.rs 12.80% 109 Missing ⚠️
boa_engine/src/builtins/temporal/duration/mod.rs 16.10% 99 Missing ⚠️
boa_temporal/src/calendar/iso.rs 13.41% 71 Missing ⚠️
boa_temporal/src/utils.rs 40.38% 62 Missing ⚠️
boa_temporal/src/iso.rs 41.34% 61 Missing ⚠️
boa_engine/src/builtins/temporal/fields.rs 0.00% 53 Missing ⚠️
... and 13 more
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.
📢 Have feedback on the report? Share it here.

@nekevss nekevss changed the title WIP - Migrate Temporal to its own crate. Migrate Temporal to its own crate. Nov 14, 2023
@nekevss nekevss marked this pull request as ready for review November 14, 2023 01:43
@nekevss
Copy link
Member Author

nekevss commented Nov 14, 2023

Marking this as ready for review as I think this is probably a good starting point to continue from for the crate. Date, Duration, DateTime, and the ISO fields have been migrated. The calendar protocol has also been moved over and can support a safe user defined "CustomRuntimeCalendar" implementation, which at the very least makes me a lot more comfortable with moving forward with this.

General thoughts:
There are definitely some points that can be improved on with future PRs (or this one if someone wants it added) or came up while migrating this.

  1. The CalendarFields and Calendar.prototype.fields implementation is not complete in this migration and I need to reason about it more, at least spec-wise. My initial thought is that there needs to be an update to the CalendarProtocol or a new super trait entirely which felt outside of the scope for this PR specifically.

  2. It would probably be worthwhile to migrate the ISO8601 parsing and nodes over to this crate as well, but it seemed like that could be completed in another PR as well if it was deemed as needed.

  3. RoundingMode was copied over but not removed from builtins/options.rs due to RoundingMode being used in intl as well, I wasn't entirely sure what the preferred approach would be as far as, intl using the temporal crate's RoundingMode or keep them separate.

  4. As in the above edit, I wasn't entirely clear what name/version should be put on this crate. I went with boa_temporal and the workspace version for consistency across the project. But as this crate would be rather nascent, I'm almost wondering if it should have a separate version (e.g. 0.0.1) that would better communicate the library's current state.

@nekevss nekevss requested a review from a team November 14, 2023 02:23
@nekevss nekevss added the Internal Category for changelog label Nov 14, 2023
@nekevss nekevss added this to the v0.18.0 milestone Nov 14, 2023
@nekevss nekevss force-pushed the temporal-crate-migration branch 2 times, most recently from 568206d to ac545bf Compare November 21, 2023 01:43
@jedel1043
Copy link
Member

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.

@nekevss
Copy link
Member Author

nekevss commented Nov 21, 2023

Agreed 😄 I just wanted the branch to be up to date and ready if the decision was to move forward with it.

@jedel1043 jedel1043 added the waiting-on-review Waiting on reviews from the maintainers label Nov 29, 2023
@jedel1043
Copy link
Member

@raskad @HalidOdat will try to review this in the next few days.

Copy link
Member

@HalidOdat HalidOdat left a 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 :)

@raskad
Copy link
Member

raskad commented Dec 3, 2023

@jedel1043 I think Github will not let us merge this until you have approved the PR because you requested changes.

Comment on lines +29 to +33
#[derive(Debug, Clone)]
pub struct TemporalError {
kind: ErrorKind,
msg: Box<str>,
}
Copy link
Member

@jedel1043 jedel1043 Dec 3, 2023

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.

Copy link
Member Author

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.

}
}

fn month_code_to_integer(mc: TinyStr4) -> TemporalResult<i32> {
Copy link
Member

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.

Copy link
Member

@jedel1043 jedel1043 left a 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.

///
/// Temporal Equivalent: 3.5.13 `AddDate ( calendar, plainDate, duration [ , options [ , dateAdd ] ] )`
#[inline]
#[cfg(feature = "context")]
Copy link
Member

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.

@jedel1043
Copy link
Member

I think Github will not let us merge this until you have approved the PR because you requested changes.

Yeah, I have a comment that definitely should be resolved before merging this.

Copy link
Member

@jedel1043 jedel1043 left a comment

Choose a reason for hiding this comment

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

Nice work!

@jedel1043 jedel1043 added this pull request to the merge queue Dec 4, 2023
Merged via the queue into main with commit e51e628 Dec 4, 2023
14 checks passed
@jedel1043 jedel1043 deleted the temporal-crate-migration branch December 4, 2023 03:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Internal Category for changelog waiting-on-review Waiting on reviews from the maintainers
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants