This commit fixes an improper_ctypes warning when bridging transparent
structs that contain non FFI safe types.
While transparent structs that contained non FFI safe types were being
passed in an FFI safe way before this commit, the Rust compiler could
not know that what we were doing was FFI safe.
This commit uses #[allow(improper_ctypes)] to silence the lint.
warning: `extern` block uses type `RustString`, which is not FFI-safe
--> my_file.rs:4:12
|
4 | struct SharedStruct {
| ^^^^^^^^^^^^ not FFI-safe
|
= help: consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct
= note: this struct has unspecified layout
= note: `#[warn(improper_ctypes)]` on by default
This warning was a bit misleading in that it made it seem like the
RustString needed a #[repr(C)] annotation.
The real issue was that the generated FFI representation type:
was triggering a warning because the Rust compiler can't know that the
non-FFI safe std::string::RustString is not being dereferenced on the
Swift side.
This commit fixes an
improper_ctypes
warning when bridging transparent structs that contain non FFI safe types.While transparent structs that contained non FFI safe types were being passed in an FFI safe way before this commit, the Rust compiler could not know that what we were doing was FFI safe.
This commit uses
#[allow(improper_ctypes)]
to silence the lint.Illustration
Before this commit the following bridge module:
would lead to the following warning:
This warning was a bit misleading in that it made it seem like the
RustString
needed a#[repr(C)]
annotation.The real issue was that the generated FFI representation type:
was triggering a warning because the Rust compiler can't know that the non-FFI safe
std::string::RustString
is not being dereferenced on the Swift side.