Skip to content
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

Merged
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 5 additions & 2 deletions src/codegen/function.rs
Original file line number Diff line number Diff line change
Expand Up @@ -438,9 +438,12 @@ pub fn body_chunk_futures(
let c_par = &analysis.parameters.c_parameters[par.ind_c];

let type_ = env.type_(par.typ);
let is_str = matches!(*type_, library::Type::Basic(library::Basic::Utf8));
let is_str = matches!(type_, library::Type::Basic(library::Basic::Utf8));
let is_slice = matches!(type_, library::Type::CArray(_));

if *c_par.nullable {
if is_slice {
Copy link
Member

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 :)

Copy link
Contributor Author

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

Copy link
Member

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

Copy link
Contributor Author

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 ifs 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

Copy link
Member

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.

writeln!(body, "let {} = {}.to_vec();", par.name, par.name)?;
} else if *c_par.nullable {
writeln!(
body,
"let {} = {}.map(ToOwned::to_owned);",
Expand Down
Loading