Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Fix #641 #644
Fix #641 #644
Changes from 2 commits
96c8bec
1fba11e
88e1037
5b1b585
57cebc5
048771f
dca57fb
6700bf7
3c83c7b
b99d71b
1e43acc
a515999
e979043
3b46708
8ad07b5
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
issue: I still don't think this is the best way to structure this
I don't think this parameter should be necessary. We're manually doing
slice.ptr, slice.size
above, so what we have is that two codepaths callinggen_js_to_c_for_type
, one which uses...{}.splat()
to splat it, and one which manually spreads it, and we have thisconversion
parameter to deal with that divergence.gen_js_to_c_for_type
already unconditionally returns a...struct.toFFI()
for structs, so all of its call sites already expect spread operators. I think it should unconditionally return...slice.splat()
for slices (with caveats on the arena behavior). The call sites should be adjusted to handle that for slices; that will simplify them since currently this call site special-cases slices and manually spreads it.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.
(all of this is an unfortunate consequence of how slices need to be special snowflakes for borrowing, which makes it easy to accidentally write code tha treats them as more special than they need to be)
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.
Yeah, it's probably for the best that we try to aim for near-universal usage of
...splat()
ingen_js_to_c
, it's just an absolute pain for freeing. I think I'll be able to make a clean solution though.