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/
