This is kind of what mrustc does? It's a Rust-to-C compiler in C++; one which assumes the Rust program is correct (i.e. passes type/borrow check). But you stil

This is kind of what mrustc does? It's a Rust-to-C compiler in C++; one which assumes the Rust program is correct (i.e. passes type/borrow check). But you still need to resolve types to do dispatch, so that's a nontrivial amount of work. mrustc can currently compile rustc, but the produced rustc doesn't pass the entire rustc testsuite (yet). A colleague of mine was considering writing a Rust-to-C++ compiler that was similar, but offloading most of the dispatch/resolution work onto C++. This is actually possible, you can turn method dispatch and autoderef into template resolution. You can do stuff to fake type inference too if you know the program is correct already. This is much harder however and I'm not yet sure if it's 100% possible without doing some typechecking in the Rust-to-C++ compiler itself. You could however take rustc --unpretty=typed (or whatever that option is these days) output and transform that really easily. This requires you to be able to independently verify that the two ASTs are equal if you resugar, because you can't trust rustc's output for this. In fact, the poc trusting trust attack I wrote[1] would still go under the radar here. Verifying ASTs as semantically equal is much less work. But there's a loophole here, it is possible to add type annotations to type inference'd Rust to get different behavior. This is because (among other things) integers are inferred more loosely (an uninferable integer type is defaulted as u32). It's possible that a trusting trust attack would be able to propagate itself merely by flipping around the results of inference. Even if we looked out for that, you still have the problem of dispatch, where a backdoored rustc could change the method being dispatched to be a different trait. Now this isn't something that would work if you assume that the original code was code which compiled fine with rustc (because rustc complains when there's unqualified ambiguity). But we can't actually trust the original compiler to have handled this correctly either! In both cases there would be need to be traces of weird code in rustc for this to work, but it might be possible to hide this. (This is also somewhat a problem for mrustc, but to much a lesser degree) [1]: http://manishearth.github.io/blog/2016/12/02/reflections-on-rusting-trust/ http://manishearth.github.io/blog/2016/12/02/reflections-on-...