From ttm|gue|tt @end|ng |rom gm@||@com  Mon Apr  3 15:50:03 2023
From: ttm|gue|tt @end|ng |rom gm@||@com (Michael Milton)
Date: Mon, 3 Apr 2023 23:50:03 +1000
Subject: [Rd] Breaking Change in Rcomplex Layout?
In-Reply-To: <e8c052d6-50ae-002d-71ba-5e160b56d419@gmail.com>
References: <CAPZyOoLG7Bgt0D_Nz-pdBv5k0_SmpFN9UuFE1-mKQxX76L=21g@mail.gmail.com>
 <e8c052d6-50ae-002d-71ba-5e160b56d419@gmail.com>
Message-ID: <CAPZyOoL7rLbLHwQMziADwg_Dy-UGNScdwi3wf_RawWyU2Y4v-Q@mail.gmail.com>

Okay, but I'm afraid this will only mean something to Rust users. The
reason being that we encountered this issue in extendr: a Rust extension
library for R. The specific compiler errors we encounter happen because
bindgen (the Rust code generation library) read the changed R header files,
and generated a new type definition for Rcomplex. Then, our downstream code
that uses that bindgen-generated code caused rustc compiler errors such as:

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`

and

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

However, to put this into context, I would expect that C, C++ packages
would encounter a similar issue if they tried to access or modify specific
Rcomplex fields in the same way.

On Mon, Apr 3, 2023 at 11:39?PM Tomas Kalibera <tomas.kalibera at gmail.com>
wrote:

>
> On 4/3/23 14:07, Michael Milton wrote:
> > Hi all,
> >
> > There seems to have been a breaking change in the R trunk caused by a fix
> > to bug 18430 <https://bugs.r-project.org/show_bug.cgi?id=18430> that
> > relates to the layout of the Rcomplex typedef. Previously it was a
> struct,
> > but now it's a union by default
> > <
> https://github.com/r-devel/r-svn/commit/862f9f816ff3ff3cb3f851603f19e99f60a98475#diff-e9b09a44d9dc69444eca2300325e790a0cc6d2c8c3960f47519c7f8ef896f9e4
> >,
> > which breaks downstream code that relied on this layout. I'm aware of
> > the R_LEGACY_RCOMPLEX variable, but I still wouldn't expect an unreported
> > breaking change especially if it's aimed at R 4.3 (although I'm not sure
> if
> > it is). I believe src/include/R_ext/Complex.h, which this patch affects,
> is
> > considered part of the public R ABI since it's included by R.h.
> >
> > What should I, as a downstream package developer, do about this change?
>
> Please report the actual problem you have ran into.
>
> Thanks
> Tomas
>
> >
> > Cheers.
> >
> >       [[alternative HTML version deleted]]
> >
> > ______________________________________________
> > R-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>

	[[alternative HTML version deleted]]



[Rd] Breaking Change in Rcomplex Layout?
Michael Milton