We kinda gave up on translating C into D, as many C constructs were unduly awkward to represent in D. What's working much better is to incorporate a C compiler directly into the D compiler. No need to translate, and the C semantics can be adhered to exactly. (The D compiler is extended to understand the C semantics coming from the C code, although that isn't part of the D specification.)
While your approach to this in D is super-cool, and I love seeing more projects embracing it (e.g. `zig cc` for cross-compiling C code), I think it solves a different problem to what they're tackling here.
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.
The trouble with translating existing C code, for example, a .h file, is the .h file vendor changes it. Then you've got to figure out what changed, and fold in the differences to the translated file.
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.
I don't think the idea here is to use it on third party dependencies, I think the idea is "we have this C code base that we maintain, and we really wish it was a rust codebase instead".
It's a nice idea, but in my experience very few people want to do that, even with a tool to help. What they do want is to be able to seamlessly interact with their existing code base the way it is.
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.
Yes, interop is a much more common use case, but this just isn't the tool for 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.
I agree that in general most want to integrate new languages with their existing code bases (rust-bindgen automatically generates C bindings, ABI tests, etc. using libclang to access C and C++ from Rust, and for each language there are tools to generate bindings and ABI tests for Rust code, e.g., the cpp crate generates C++ wrappers around Rust libraries).
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.
> It's a nice idea, but in my experience very few people want to do that
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.
It would be nice to have a language independent header format intended for sharing readable information about .so files. .h files are just not good enough as they can embed arbitrary C and thus forces whatever is going to use it to also be a C compiler.
> We are developing several tools that help transform the initial Rust sources into idiomatic Rust.
(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.
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!
I've considered compiling into C code, but after seeing what cfront (compiles from C++ to C) had to go through, I figured that would be a ton more work than just generating code directly!
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.
Please clarify what do you mean by incorporating a C compiler. Does this mean you're abandoning the "custom C frontend inside the D compiler" effort in favor of something like clang? To me, the other possibility - having *yet another* C compiler to look out for - is just terrifying.
Won't this require years of busywork? The various intrinsics, function attributes, C compiler args compatibility, ABI profiles for various platforms/systems (including the Windows GCC/VC ABI idiocy?)
upd: Also, I'm not sure that implementing -funsigned-char in 2022 will be all that great for morale!
