[Merged by Bors] - Refactor the Date builtin#2449
Conversation
Test262 conformance changes
Fixed tests (10):Broken tests (4): |
Codecov Report
@@ Coverage Diff @@
## main #2449 +/- ##
==========================================
+ Coverage 52.39% 52.52% +0.13%
==========================================
Files 330 329 -1
Lines 35041 34793 -248
==========================================
- Hits 18359 18276 -83
+ Misses 16682 16517 -165
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
|
Please file an issue against the chrono project instead of requesting a feature in a PR to your own project. (Adding such a feature could make sense, I suppose.) |
Thanks for the quick response! Just wanted to confirm with you before opening an issue, mainly to avoid polluting the issue tracker with unfeasible feature requests :) |
Razican
left a comment
There was a problem hiding this comment.
Looks pretty good! Thanks :) I added some comments in places where I saw the code could be enhanced. It's an interesting usage of the const generics, btw! maybe this needs a minimum supported rust version bump?
6db29c1 to
658d685
Compare
We set |
|
bors r+ |
Just a general cleanup of the `Date` builtin to use slightly better patterns and to fix our warnings about deprecated functions. About the regressed tests. It seems to be a `chrono` bug, so I opened up an issue (chronotope/chrono#884) for it and they've already opened a PR fixing it (chronotope/chrono#885). However, while checking out the remaining failing tests, I realized there's a more fundamental limitation with the library. Currently, [`chrono`](https://github.com/chronotope/chrono) specifies: > Date types are limited in about +/- 262,000 years from the common epoch. While the [ECMAScript spec](https://tc39.es/ecma262/#sec-time-values-and-time-range) says: > The smaller range supported by a time value as specified in this section is approximately -273,790 to 273,790 years relative to 1970. The range allowed by the spec is barely outside of the range supported by `chrono`! This is why the remaining `Date` tests fail. Seeing that, I would like to ping @djc and @esheppa (the maintainers of `chrono`) to ask if it would be feasible to add a feature, akin to the `large-dates` feature from the `time` crate, that expands the supported range of `chrono`. EDIT: Filed chronotope/chrono#886
|
Pull request successfully merged into main. Build succeeded: |
Date builtinDate builtin
This Pull Request restructures the lint deny/warn/allow lists in `boa_engine`. It adds a lot of documentation to pup functions. There are still a few clippy lints that are not fixed, mainly regarding casting of number types. Fixing those lints effectiveley would in some cases probably require bigger refactors. This should probably wait for #2449 to be merged, because that PR already fixes that lints regarding the `Date` built-in.
Just a general cleanup of the
Datebuiltin to use slightly better patterns and to fix our warnings about deprecated functions.About the regressed tests. It seems to be a
chronobug, so I opened up an issue (chronotope/chrono#884) for it and they've already opened a PR fixing it (chronotope/chrono#885).However, while checking out the remaining failing tests, I realized there's a more fundamental limitation with the library. Currently,
chronospecifies:While the ECMAScript spec says:
The range allowed by the spec is barely outside of the range supported by
chrono! This is why the remainingDatetests fail.Seeing that, I would like to ping @djc and @esheppa (the maintainers of
chrono) to ask if it would be feasible to add a feature, akin to thelarge-datesfeature from thetimecrate, that expands the supported range ofchrono.EDIT: Filed chronotope/chrono#886