Description

C2Rust is an extra that occasionally causes trouble, eg. in #19495 (comment), where I was tempted to answer:

Yes, getting rid of c2rust would be an interesting goal, but a lot of our API surface is not actually API in the symbols-types-and-linker sense and more in the preprocessor-and-static-inline sense. Last time I checked there was a great many things that were only accessible through the latter in RIOT, too many to change on the short term, and without other users than Rust. (I've seen some usage from C++ where things like mutex_trylock_ffi, but just grepping for 'inline' (eg. in riot_sys::inline which is where the c2rust items come through, or in crate::inline_cast which converts the types of bindgen and c2rust with extra checks) reveals a lot of locations, and that's not yet accounting for the toplevel_from_inline list (26 items in riot-sys' build.rs) that makes sure things also work for items that are possibly static depending on the platform. A lot of these have not been checked in a while, but unless we aim to go full clean-API, there'd be c2rust left.

… so instead, I'm opening this.

I'm not sure now is a good point in time, neither ever, but let's at least use this issue to hypothesize, and to collect material, show-stoppers and input.

Why we use C2Rust now

• API surface in RIOT is not clean API but a mixture of exported symbols, static inlines and preprocessor. bindgen works well when linking against a library, but RIOT is not designed to be used as a library.
  • We'd need to get rid of, or have equivalent versions, of all preprocessor macros that are regularly used.
  • We'd need to make all static inline functions usable from a linked program. I'm marking this as "solved" because bindgen has learned to turn public static functions into non-static functions that can be linked when an extra generated C file containing all their implementations is linked -- so there is a viable solution, but see next point.
• Performance reasons: The reason for having functions static functions is that it allows inlining, and many such functions are on hot paths. Wouldn't be too bad, if we could
  • Fix everything that's broken when using LTO. (I'm not sure there's anything left, last time I checked was ages ago, but our CI doesn't use it, and if it ain't tested it ain't working)
  • Allow linking with non-GCC linkers
    for then we could both C and Rust code into LLVM object files and do cross-language LTO to eliminate any drawbacks of using non-static functions. (Cross-language LTO may have other issues, but right now we can't even test it because RIOT only works with ).

If we could tick all these boxes, we could migrate off C2Rust. But that'd probably only fly if there were other reasons as well that'd justify ticking the boxes. Do we have them?