FTA:
> We are developing several tools that help transform the initial Rust sources into idiomatic Rust.
It sounds like this translator they've built may be meant primarily as the first part of a pipeline of tools to help you eventually translate existing C code into idiomatic Rust, rather than just letting you compile C code using the Rust compiler.
The only use case I can imagine personally having for this tool _on its own_ would be in avoiding the hell of trying to target musl with a project that mixes Rust and C.
It sounds easy enough in theory, but in practice, it's a nightmare. For example, you have no clue if the enum values changed, or the api's acquired an extra argument. Being C, the linker won't give you a clue, either.
This problem simply vanishes when your XLang compiler can actually compile C files.
Examples: C and C++, Java and Kotlin. The latter advertises: "Write concise and expressive code while maintaining full compatibility and interoperability with Java" and has been very successful with that.
Rust-bindgen is. Which "just" tries to translate header files, since rustc can link to C object files just fine. And for what it's worth, I'm pretty sure most of your complaints do apply to that tool.
The consultancy company developing c2rust specifically helps clients translate their apps to Rust. IIUC these clients want to move from C to a memory and thread safe language without loosing performance.
c2rust is the first step in that process. It mechanically translates C into "C-looking unsafe Rust".
The engineers then go and start migrating from unsafe Rust to safe Rust incrementally.
This is a long process, c2rust speeds up a small fraction of it, but most of the engineers time is spent into translating unsafe Rust into safe Rust, and then refactoring safe Rust into idiomatic Rust.
Maybe it's relatively few, but they exist, and this is targeting serving their needs. There are other tools serving C/Rust interop use cases, and at a certain point the “this isn't the most common use case” dismissal is just tedious.
HN shouldn't be a place where things targeting real but narrow technical niches are dismissed because the niche is narrow or there is a much bigger superficially related one around.
(2019) C2Rust hasn't changed much in a few years.
The Rust you get out of C2Rust is a representation of the pointer semantics of C in unsafe Rust using a library of functions that emulate C operations. This is only useful if you desperately need to compile C with a Rust compiler.
Intelligent conversion of C to Rust is hard, and less useful as time goes on and more lower-level crates become available for Rust.
1. C tag name space
2. enum values are placed into the enclosing scope
3. structs defined within a struct definition don't go into that definition's scope
4. `if (a = b)` is not allowed in D
5. unprototyped C function declarations
6. C bit fields
7. C struct declarations without a definition
8. oddities of _Alignas and _Alignof behavior
9. _Generic
10. all the weird C compiler extensions
11. etc.
All these things wind up making translation about 95% feasible, and the rest is a mess.
Was compiling into C a consideration? Seems like this side steps some of the compatibility issues (not to mention getting a lot of optimization "for free"), albeit while inheriting any compilation and ABI limitations.
Thanks! P.s. We met at GoingNative2013 - you were very kind with my many questions back then as well!
Glad I was able to help you at GN2013!
Basically all compilers should be multi-lingual. Especially, rustc given its abilities with the borrow checker. Ideally (within reason for maintenance reasons), even parsers as “plugins”. Still building the same HIR (or AST if applicable) within rustc, but with different parsers.
I’d love to see lot of experiments with Rust syntax in the vein of how CoffeeScript inspired the future of JavaScript.
But still getting all the benefits of incremental compilation, cargo, etc.
No. It means the custom C frontend inside the D compiler, with the semantic routines in the D compiler tweaked where necessary to support C semantics.
upd: Also, I'm not sure that implementing -funsigned-char in 2022 will be all that great for morale!