-
-
Notifications
You must be signed in to change notification settings - Fork 484
Remove more usages of JsStr in favor of just JsString #4578
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
Conversation
Test262 conformance changes
|
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #4578 +/- ##
===========================================
+ Coverage 47.24% 57.65% +10.41%
===========================================
Files 476 531 +55
Lines 46892 58764 +11872
===========================================
+ Hits 22154 33881 +11727
- Misses 24738 24883 +145 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
nekevss
left a comment
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.
Looks good to me! 😄
Move the following to
JsString(fromJsStr):getandget_expectnow returnJsString. Usescode_point_at()instead ofget(usize)JsStringbeing displayed. Using aJsStringreference instead of a clone makes it clearer that callingstring.display()should be temporary (and has a lifetime).JsStringand returnJsStringdirectly.JsStringAPI and itsvtable.trim()not slicing twice.JsStringfrom a slice is as fast (thanks toSliceString) than aJsStron a slice, but creating aJsStringfrom it is faster now.The end goal is to get rid of
JsStrin its current form.Benchmarks on my machine: