8 ms·
As background, this is a separate effort from the "GCC Rust" project. This project is using libgccjit, which is basically a library interface to GCC (intended
by geofft 5y ago
As background, this is a separate effort from the "GCC Rust" project.
This project is using libgccjit, which is basically a library interface to GCC (intended for JITs, but here being used for ahead-of-time compilation), as an alternative to LLVM for the standard Rust compiler ("rustc" aka https://github.com/rust-lang/rust https://github.com/rust-lang/rust). This allows reusing all the logic inside the Rust compiler for compiling code, checking types and lifetimes, etc. while targeting platforms that LLVM does not support.
The GCC Rust project https://rust-gcc.github.io/ https://rust-gcc.github.io/ is an alternative implementation of Rust inside the GCC project, in much the same way that, say, gccgo is an alternative implementation of Go or GCJ is an alternative implementation of Java. It's adding a Rust frontend to GCC, instead of adding a GCC backend to rustc.
From a pure functionality standpoint, the libgccjit approach is preferable, because as soon as a feature is in rustc, it's usable. You share the same implementation.
Personally, I'm very happy to see it approved because it immediately solves a difficult issue with getting Rust into the Linux kernel - that the Linux kernel supports many more architectures than LLVM does, and rustc doesn't even support all of those (https://github.com/fishinabarrel/linux-kernel-module-rust/issues/112 https://github.com/fishinabarrel/linux-kernel-module-rust/is... is where things were last time I looked in detail), and without some answer for how to get things to compile on every architecture, Rust kernel code will have to be limited to drivers that are only used on architectures that Rust supports.
From an avoiding-monoculture standpoint, GCC Rust is preferable specifically because it's an alternative implementation. I think it will be good, long-term, to have that as an option too.
Also, as I understand it, a reason that the company behind grsecurity is sponsoring GCC Rust is that they have various GCC compiler plugins for hardening, and those would apply straightforwardly to GCC Rust, but they wouldn't necessarily apply to libgccjit. From https://opensrcsec.com/open_source_security_announces_rust_gcc_funding https://opensrcsec.com/open_source_security_announces_rust_g... :
> As the source of the GCC plugin infrastructure in the Linux kernel and nearly all of the GCC plugins adapted for inclusion in the upstream Linux kernel, we too immediately spotted the importance of this problem and set out to ensure both those plugins as well as the security features built-in to GCC itself are able to instrument code from all languages supported by the Linux kernel with compatible and consistent security properties.
- nynx 5y agoI disagree that multiple frontend implementations is going to be a good thing for Rust. Multiple backends is great, but multiple frontends could result in Rust getting held back to the lowest common denominator. C and C++ have multiple frontends because of proprietary nonsense. Rust doesn’t have that problem.
- apendleton 5y agoFWIW, an alternative outcome to lowest-common-denominator is what's happened with, for example, alternative Python implementations: there's still a main blessed one, most library authors don't care about whether or not anything works on any of the others, and users who want to avail themselves of the benefits of one of the alternatives (e.g., better runtime performance on PyPy) probably just can't, if the libraries they need aren't supported, unless they go to the effort of adding support themselves. (This outcome is probably also bad, to be clear, but maybe of less practical consequence to people who continue to use mainline rustc.)
- nynx 5y agoYeah, that outcome is still pretty bad. I don’t think there’s any value gained from multiple frontends here. It’s unlike the PyPy situation in that a Rust GCC frontend is not going to have better performance, at least at runtime, from rustc with a GCC backend. Any compile performance differences could be resolved.
- kzrdude 5y agoGCC vs llvm competition has been beneficial for C++, though
- nynx 5y agoAnd it's going to be beneficial for Rust too. Just there's no reason to have multiple frontends.
- cmrdporcupine 5y agoThis is new, though. Back in the 90s and early 2000s the compiler situation for C++ held back the language because the intersection of features from the "standard" available through both MSCV and GCC wasn't ideal. Both were good compilers. But in different ways. Nowadays it's pretty trivial to get a codebase to compile across MSVC, GCC and Clang. Back then it was often weeks and weeks of work.