Impediments to transpiling Rust to C?

internals.rust-lang.org

5 points·nuclx··9 comments

Nobody in C land uses - fstrict-aliasing, hence the argumentation is absurd.

Indeed. Support for -fno-strict-aliasing and -fwrapv can be expected for modern C compilers, so I don't see any real hurdles besides the obvious engineering and maintenance effort required to support a robust transpiler.

There’s also one that exists, so that proves it can be done: https://github.com/thepowersgang/mrustc

So there is hope to overcome the "not as portable as C" showstopper.

Yes, though with important caveats:

* mrustc doesn't implement a borrow checker.

* mrustc's original goal was to bootstrap rustc, and so it's based on Rust 1.19 as of now.

So, it's not a panacea, but it is proof that it can be done.

No borrow checker is intentional. I believe the intended workflow is that one uses the regular Rust compiler for that. Which should be doable for embedded systems (for which I think mrustc is most relevant for), as it supports cross-compiling rather well.

Totally! I think it is the right choice. But I wanted to be clear about what it actually is, that’s all!

Compile to LLVM IR then target C?

-march=c was apparently removed from LLVM? See https://stackoverflow.com/questions/5180914/llvm-ir-back-to-...

I didn't know that it existed in the first place and what i expected was a bit of a higher level approach. Not even sure if going through Rust -> LLVM IR -> C -> asm would have a negative effect on performance, i.e. if the C code reconstructed from LLVM IR is optimal.

Reply on news.ycombinator.com