-
-
Notifications
You must be signed in to change notification settings - Fork 98
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
codegen/function: body future handles ownership of slice argument #1580
base: master
Are you sure you want to change the base?
codegen/function: body future handles ownership of slice argument #1580
Conversation
CI is failing, but I don't think it is related with the changes:
|
|
||
if *c_par.nullable { | ||
if is_slice { |
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.
Would also support a nullable slice while at 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.
AFAIK, nullable
annotation on array still produces a &[]
(and not a Option<&[]>
). So to_vec
still applies
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.
AFAIK, nullable annotation on array still produces a &[] (and not a Option<&[]>). So to_vec still applies
That is an issue that should be fixed separately, see #1551
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.
However, that PR is still not merged.
If I change my code assuming I can have Option<&[]>
, that is:
if *c_par.nullable {
...
} else if (is_slice) {
...
} ...
I'd end up still having a bug generated code until that PR kicks in.
Isn't it better to change the if
s order in #1551 where the logic actually changes?
(P.S: why having Option<&[]>
. That's not rust idiomatic. the current behavior (if I am not mistaken): &[]
even when array is annotated as nullable
makes sense in the generated rust type
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.
Sometimes there is a difference in behaviour between passing None
and &[]
. See #1133 (comment) but agree, that can be done in the other PR.
Currently, the future body generated is something like:
both approaches fail to compile as:
.map
does not exist forslice
type (it is not anOption
).clone()
does not really give ownership of the data slice, asclone
only copies the wide-pointer.static
lifetime (and that's the reason why the code in the generator performs aclone
orto_owned
in the first place).This PR aims to handle the case of slice argument