extendr: Rcplx is broken on R-devel
Originally filed at https://github.com/extendr/libR-sys/issues/149.
R-devel changed the definition of Rcomplex
a few days ago (https://github.com/r-devel/r-svn/commit/862f9f816ff3ff3cb3f851603f19e99f60a98475) in order to match the C representation of complex with Fortran’s representation (see https://bugs.r-project.org/show_bug.cgi?id=18430 for the details).
In short, Rcomplex
is now a union, while the current exendr code assumes it’s a struct. So, now extendr won’t compile with the following error. We have to deal with this. I hope I can have time to fix this soon, but I’d appreciate if anyone can take a look because I’ve never used complex numbers…
error[E0560]: union `libR_sys::Rcomplex` has no field named `r`
--> extendr-api\src\robj\into_robj.rs:93:20
|
93 | Rcomplex { r: 0., i: 0. }
| ^ `libR_sys::Rcomplex` does not have this field
|
= note: available fields are: `__bindgen_anon_1`, `private_data_c`
error[E0560]: union `libR_sys::Rcomplex` has no field named `i`
--> extendr-api\src\robj\into_robj.rs:93:27
|
93 | Rcomplex { r: 0., i: 0. }
| ^ `libR_sys::Rcomplex` does not have this field
|
= note: available fields are: `__bindgen_anon_1`, `private_data_c`
error[E0784]: union expressions should have exactly one field
--> extendr-api\src\robj\into_robj.rs:93:9
|
93 | Rcomplex { r: 0., i: 0. }
| ^^^^^^^^
error[E0609]: no field `r` on type `libR_sys::Rcomplex`
--> extendr-api\src\robj\mod.rs:348:56
|
348 | CPLXSXP => R_IsNA((*COMPLEX(sexp)).r) != 0,
| ^ unknown field
|
= note: available fields are: `__bindgen_anon_1`, `private_data_c`
help: one of the expressions' fields has a field of the same name
|
348 | CPLXSXP => R_IsNA((*COMPLEX(sexp)).__bindgen_anon_1.r) != 0,
| +++++++++++++++++
error[E0609]: no field `r` on type `libR_sys::Rcomplex`
--> extendr-api\src\scalar\rcplx_default.rs:105:28
|
105 | Rcplx(c64::new(val.r, val.i))
| ^ unknown field
|
= note: available fields are: `__bindgen_anon_1`, `private_data_c`
help: one of the expressions' fields has a field of the same name
|
105 | Rcplx(c64::new(val.__bindgen_anon_1.r, val.i))
| +++++++++++++++++
error[E0609]: no field `i` on type `libR_sys::Rcomplex`
--> extendr-api\src\scalar\rcplx_default.rs:105:35
|
105 | Rcplx(c64::new(val.r, val.i))
| ^ unknown field
|
= note: available fields are: `__bindgen_anon_1`, `private_data_c`
help: one of the expressions' fields has a field of the same name
|
105 | Rcplx(c64::new(val.r, val.__bindgen_anon_1.i))
| +++++++++++++++++
Some errors have detailed explanations: E0560, E0609, E0784.
For more information about an error, try `rustc --explain E0560`.
error: could not compile `extendr-api` due to 6 previous errors
warning: build failed, waiting for other jobs to finish...
error: could not compile `extendr-api` due to 6 previous errors
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 35 (35 by maintainers)
Commits related to this issue
- Provide a quick fix for extendr/extendr#524 — committed to extendr/libR-sys by CGMossa a year ago
Yes, that would be the proper fix. We can define a new
cfg
for R 4.3 here.https://github.com/extendr/extendr/blob/master/extendr-api/build.rs
It’s the version of the Graphics Device API.
https://github.com/extendr/libR-sys/blob/d113d56dd0c362ddf002e489b456face8c4c348d/bindings/bindings-linux-x86_64-R4.1.rs#L81
Yes, I meant it. Sorry, my explanation was a bit too terse.
I’m attempting this over at https://github.com/extendr/libR-sys/pull/156 Feel free to provide comments and tasks on that PR continuously, as I’ve no idea when it is sufficiently done.
Can we override the name and visibility of the generated
Rcomplex
? I think what we can do is just override its definition and then have some build-time test (like we already have in libR-sys) to verify that whatever gets bindgened from headers has an identical layout to our customRcomplex(f64, f64)
.Here’s the mailing list thread. Nothing interesting yet: https://stat.ethz.ch/pipermail/r-devel/2023-April/082517.html.
I’ve just had the realisation that I’m probably embarrassing myself though, because the C compiler might actually insulate the user from this particular layout change. It seems likely that only Rust would be affected because it forces you to handle the union in a way that C probably doesn’t, because it doesn’t attempt to be safe in the same way.
Can anyone explain why
R >= 4.1
isuse_r_ge_version_14
? Where does14
come from? https://github.com/extendr/extendr/blob/6e15390d2d4dbcd53878f4b31312c4fb68de25e6/extendr-api/build.rs#L19-L22