Right but that just means it's LLVM being clever, not rustc.
The main compiler is the self-hosting gc go compiler. Iirc ~~it's the reference implementation~~ erm I guess it's determined by spec, not reference implemenation. Gc is definitely "the default" though.
Then There's the gofrontend, which is a compiler frontend to other compilers, which can work with gcc and llvm. I am not aware of the state of the art for these, but I wonder if there are performance differences.
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). 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/ 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/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_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.
Is that expected to ever change and/or does Rust expect to work with other libcs (bionic? musl-libc?) Being able to build completely self-contained static binaries can be very nice at times, and for embedded use, glibc is pretty large...
I thought Rust used llvm for compilation? That makes the libgcc dependency seem a bit odd. Maybe I misunderstood?
For rustc with llvm maybe, but there's projects to build a GCC backend for rustc, as well as projects to build a Rust frontend for GCC, both of which could solve this.
> So long as you're just using LLVM-based compilers for both Rust and your other languages, you should be OK, but don't be surprised if you run into problems.
No. You can use the Go bindings to Rust's regex library where the regex library is compiled with `rustc` (llvm based) and your host program, written in Go, is compiled with the standard Go compiler, which is not llvm based.
This works because the Go toolchain knows how to link with objects exposing a C ABI and the Rust toolchain knows how to provide said objects. There is no particular dependency on llvm here.
Well, the good news for you then is that there is progress underway to implement Gc-as-a-library in Rust, to give you this option if you need it as well.
Thanks, because the way which snapshots of LLVM and rustc are required to build a certain rustc release does not make it an easy to use solution for common Rust users. It'd be great if an existing LLVM 3.8 can be leveraged.
It may have been nice to build it on GCC instead of LLVM. First, the existing Rust compiler uses LLVM so this won't be a fully independent implementation. Second, it would provide GCC with a Rust front end.
reply