That's rather rustc_codegen_gcc. gcc-rs is more for people who don't like LLVM and/or Rust.

https://github.com/rust-lang/rustc_codegen_gcc

A rust implementation for people who don’t like rust seems like a strange take.

Not too strange. Imagine the reverse: a C compiler written in Rust. There is an awful lot of software in C that I want to use, but I really dislike C itself. If I found some deficiency in C compilers and felt the need to write my own, I certainly would prefer to write it in Rust.

It would be a C implementation for people who don't like C.

This is eventually going to be a feature-complete compiler, targeting a specific rustc version. I believe the plan is to use polonius [1], presumably as an "optional" feature so they can build a stage 1 without it, use that to build polonius, then build the final compiler with it included.

[1] https://github.com/rust-lang/polonius

You are right, this much more ambitious than I though! Here is more information about the project, for the curious: https://rust-gcc.github.io/

It seems like an odd idea to release a Rust compiler without a borrow checker. Isn't there a high risk that it will confuse users into thinking they have the usual Rust guarantees at run-time?

This can be very useful for platforms where rustc is not available due to LLVM not supporting them. Take a project, build it with rustc, and if it builds, you know it passes the borrow checker. It is then safe to build it for your actual target with gcc. This would limit the outcry when some software adds a dependency on Rust, like the python crypto thing of a few years back, or the Linux kernel.

Why not use this instead?

https://github.com/rust-lang/rustc_codegen_gcc

This will still use the official rustc frontend. For what I described above, this is not an issue, it would totally work. However, there are cases where having a pure gcc implementation (frontend + backend) is beneficial.

As others have mentioned, vendors have the standard practice to fork gcc for their hardware, but not necessarily rustc nor libgcc used by rustc_codegen_gcc. This means that rust will be possible on those platforms for free thanks to gcc-rs.

Another point is the bootstrapping of the compiler. rustc has a quite complex bootstrap process that depends on python, while afaik gcc only relies on shell scripts. It is much easier to port gcc than rustc to a new host platform. This is useful when you want to compile code directly on your target and don't want to rely on cross compilation. cross compiling is a tricky thing to do, and while rust fares pretty well there, as soon as it uses native C libraries, it all falls apart (e.g. try cross compiling a project that has dependencies on libss, libpq and the like). In such case, native compilation may be the only viable option. And most of the times, GCC is the first thing to be ported, so you would not need to wait for a rustc port.

Borrow checker is compile time. There is no reason to have multiple implementations.

Yup, it's compile-time, and gives you run-time guarantees.

I think the expectation for now is that people will develop an app with rustc and then use gcc to compile to targets that aren't yet supported by llvm.

That could be a feature. I'm making a joke, but it would be tempting sometimes when the program is correct but the borrow checker can't figure that out. The borrow checker and I don't get along all that well, even two years into the relationship.

No borrow checking is effectively a dialect of Rust?

Without a borrow checker, at best it can be considered a code generator for pre-certified Rust source code. Possibly useful, but you'd still need to have rustc in the loop.

Lacking a borrow checker is a temporary thing, no point reinventing the wheel. I think the intent is that eventually it'll use the same library as Rust (maybe Polonius, or perhaps plans will change)