[Request for Comments] Using Rust libraries in the Rust frontend

[Arthur Cohen <arthur.cohen@embecosm.com>]

Hi everyone,

In order to increase the development speed of Rust features, we are 
seeking feedback on reusing some Rust components directly within our 
front-end. As mentioned in other conferences, the most important 
component we would like to integrate into the front-end is the polonius 
borrow-checker. Another component we've become interested in is the 
`rustc_format_parser` library, responsible for handling parsing and 
handling of format arguments as described in the documentation for 
`std::fmt` [1].

However, since these libraries are written in Rust, GCC in itself is not 
yet able to compile them. They all depend on the Rust standard library, 
which we cannot yet compile and link properly. This obviously raises a 
question - how to actually compile, integrate and distribute these 
components?

We do have the option to rewrite them from scratch, but we feel that 
spending time on these existing, correct, battle-tested and easily 
integrable components instead of focusing on other aspects of the 
language would be a mistake. Spending this time instead on Rust features 
that we are missing for compiling these components would, in our 
opinion, yield more results, as it would also help in compiling other 
Rust programs.

We could either distribute these components as compiled libraries, or 
look at integrating the official Rust compiler to our build system as a 
temporary measure. I am aware that this would mean restricting the Rust 
GCC front-end to platforms where the official Rust compiler is also 
available, which is less than ideal. However, this would only be 
temporary - as soon as the Rust front-end is able to compile these 
components, we would simply reuse them and compile them with gccrs as 
part of our bootstrapping process.

The documentation for `std::fmt` [1] describes all of the features 
available in Rust format strings. It also contains a grammar for the 
format-string parser, which we would need to re-implement on top of 
supporting all the formatting features. As a prototype, I wrote an FFI 
interface to the `rustc_format_parser`  library and integrated it to our 
macro expansion system, which took me less than a couple hours. In less 
than an afternoon, we had bindings for all of the exported types and 
functions in the library and had access to a compliant and performant 
Rust format string parser. But re-implementing a correct 
`format_args!()` parser - with the same performance as the Rust one, and 
the same amount of features - would probably take days, if not weeks. 
And we are talking about one of the simplest components we aim to reuse. 
Something like a fully-compliant trait solver for the Rust programming 
language would take months if not years to implement properly from scratch.

I would like to stress once again that relying on distributing compiled 
libraries or using `rustc` in our build system would be temporary, and 
that these measures would be removed as soon as gccrs is able to compile 
these components from source.

I am looking for comments on this decision as well as the best practices 
we could adopt. Have there been any similar decisions for other 
self-hosted front-ends? Any previous email threads/commits that you 
could point me to would be greatly appreciated.

Thanks,

Arthur

[1]: https://doc.rust-lang.org/std/fmt/