Similar to #25368 (moved), we can once again expand upon which Rust types are safe to send over the FFI boundary without conversion/serialisation/translation, because Rust's bool type and C99's bool type are directly compatible. (I think this also makes an even larger argument moving forward for using bools in C wherever it makes sense, since otherwise we need to convert between the libc uint8_t type and the native u8 in Rust.)
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items ...
Show closed items
Linked items 0
Link issues together to show that they're related.
Learn more.
There is a postponed RFC to define Rust's bool and C99's _Bool to be FFI-compatible.
We should either postpone merging this until Rust decides to accept RFC 954 or point to that RFC (and maybe the follow up RFC 992) in our doc. There seems to be a consensus that it should be accepted but it seems they haven't gone through the formalities yet.
This patch also adds a non-ASCII character in a file that previously had none. I think we lack a style guide that covers the acceptability of non-ASCII in various files, but this is a change. On the other hand CodingStandardsRust.md already had some non-ASCII characters in it so maybe we don't actually care that much?
Unfortunately, it seems like Rust RFC 992 was closed without taking the final step of explicitly documenting the ABI equivalence of Rust's bool and C's _Bool. Further comments from a Rust core team member imply that this is unlikely to be resolved any time soon.
Trac: Resolution: N/Ato wontfix Status: assigned to closed