
Impediments to transpiling Rust to C? - nuclx
https://internals.rust-lang.org/t/impediments-to-transpile-rust-to-c/8112
======
rurban
Nobody in C land uses - fstrict-aliasing, hence the argumentation is absurd.

~~~
nuclx
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.

~~~
steveklabnik
There’s also one that exists, so that proves it can be done:
[https://github.com/thepowersgang/mrustc](https://github.com/thepowersgang/mrustc)

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

~~~
steveklabnik
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.

~~~
jononor
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.

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

------
crb002
Compile to LLVM IR then target C?

~~~
nuclx
-march=c was apparently removed from LLVM? See [https://stackoverflow.com/questions/5180914/llvm-ir-back-to-...](https://stackoverflow.com/questions/5180914/llvm-ir-back-to-human-readable-source-language)

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.

