> Cohen's EuroRust talk highlighted that one of the major reasons gccrs is being developed is to be able to take advantage of GCC's security plugins. There is a wide range of existing GCC plugins that can aid in debugging, static analysis, or hardening; these work on the GCC intermediate representation
> One more reason for gccrs to exist is Rust for Linux, the initiative to add Rust support to the Linux kernel. Cohen said the Linux kernel is a key motivator for the project because there are a lot of kernel people who would prefer the kernel to be compiled only by the GNU toolchain.
That explains why you’d want GCC as the backend but not why you need a duplicate front end. I think it’s a bad idea to have multiple front ends and Rust should learn from the mistakes of C++ which even with a standards body has to deal with a mess of switches, differing levels of language support for each compiler making cross-platform development harder, platform-specific language bugs etc etc.
> A lot of care is being put into gccrs not becoming a "superset" of Rust, as Cohen put it. The project wants to make sure that it does not create a special "GNU Rust" language, but is trying instead to replicate the output of rustc — bugs, quirks, and all. Both the Rust and GCC test suites are being used to accomplish this.
In other words, I’d love gccrs folks to explain why their approach is a better one than rustc_codegen_gcc considering the latter is able to achieve this with far less effort and risk.