feat: Implement proposal-arraybuffer-base64#4630
feat: Implement proposal-arraybuffer-base64#4630magic-akari wants to merge 1 commit intoboa-dev:mainfrom
Conversation
Test262 conformance changes
Fixed tests (63): |
|
Note
For Also, simple 4-character truncation is insufficient: whitespace affects At the moment, we do not support If we decide to go with |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #4630 +/- ##
===========================================
+ Coverage 47.24% 59.30% +12.06%
===========================================
Files 476 592 +116
Lines 46892 64160 +17268
===========================================
+ Hits 22154 38050 +15896
- Misses 24738 26110 +1372 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
f2d29eb to
2ff9f60
Compare
|
Thank you, this looks nice. Just to be clear, what would be the full list of missing things from I ask this because I plan to open a discussion with the |
|
The main missing feature is However, the ECMA-262 spec requires three distinct modes: Our current implementation works around this limitation by checking for the presence of There's another subtle issue: ECMA-262 disallows concatenated padded inputs, but As for |
|
Thank! I'll open an issue with them to see if they're open to implementing the features. |
|
ia0/data-encoding#152 (comment) Since they seem collaborative and responsive, I'd say we should merge this and try to push for the addition of the features we need. |
|
Actually I missed those requirements from #4630 (comment):
This is something I've never heard of yet. I've added it to the wish list for v3.
I missed the fact you don't use Is the |
Yes, the |
|
Thanks! I guess this is the specification: https://tc39.es/ecma262/#sec-frombase64. I'll take a look when I get time. |
|
Sorry for the long delay. That's the first week-end where I could get a chance to look at this. You can find here an example implementation of There's a few things to note:
If using that implementation on your side is satisfactory, then I can create a PR to update |
Thank you for the update. I have completed local testing of the ecma262 branch and confirmed that it passes all test262 test cases. I believe the implementation is now ready to move forward. Regarding the ecma262 module - specifically the |
|
Yes, my idea was for boa to copy and maintain the implementation locally. An alternative would be for me (or us) to publish and maintain (or co-maintain) a |
2ff9f60 to
d5ae194
Compare
Test262 conformance changes
Fixed tests (70):Tested main commit: |
|
I have updated the implementation to use the ecma262 branch of data-encoding as a dependency, which is expected to pass all tests. I will update the dependency again once a new version of data-encoding is officially released. Regarding the maintenance strategy for the ECMA-262 logic—whether it resides in a separate crate or within Boa—I will leave the final decision to @jedel1043, as I am contributing to this project as an external contributor. |
Thank you for these technical notes. |
Sounds fine to have a small crate for it (might be useful for other Rust engines such as Nova), but we can leave that for the future. In the meantime let's just bundle the code in |
| // Backtrack one symbol. | ||
| read -= 1; | ||
| extra_input -= 1; | ||
| debug_assert!(base.interpret_byte(input[read]).is_symbol()); |
There was a problem hiding this comment.
I've merged ia0/data-encoding#154 and decided is_symbol() should return an Option instead of a bool (to avoid losing possibly useful information). So you'll need the following change once the Cargo.toml points to the default branch, and once I'll release the change (in about 2 weeks to let it cool down).
| debug_assert!(base.interpret_byte(input[read]).is_symbol()); | |
| debug_assert!(base.interpret_byte(input[read]).is_symbol().is_some()); |
Uh oh!
There was an error while loading. Please reload this page.