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.
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.
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.
9 comments
[ 2.9 ms ] story [ 68.1 ms ] thread* 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.
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.