If GNU please: Rust support merged for the forthcoming GCC 13

Preliminary support for compiling the Rust language has been merged into the codebase for GCC 13, which will be the next version of the GNU compiler collection. The Reg's sister site DevClass reported on the approval back in July, along with a timeline of when to expect the next steps, and now the code merge has happened. This …

[Evil Scot]

GNU

Relay this message.

Do Not Log.

Return back at terminus.

[Duke of Source]

Re: GNU

A while back I was using debops (sic) to configure my servers and was quite surprised to see the web server emit a X-Clacks-Overhead header...

[Anonymous Coward]

Now built in C++

"GCC, like much of the GNU Project, is built in C."

Ummm, the plan to move to C++ was announced in 2008. The last few releases even require C++11.

[Liam Proven]

Re: Now built in C++

[Author here]

Fair point.

I was merely pointing out why the GNU project rejected Apple's patches back then, though.

But I should have pointed that out, e.g. via

https://lwn.net/Articles/542457/

[hsmyers]

Also ran…

I believe I saw a similar article on Modula-2?

[Liam Proven]

Re: Also ran…

[Author here]

My piece on that and the current SOTA in FOSS Wirthian languages should be published tomorrow. :-)

[ssokolow]

> The last time we wrote about it, when covering Linus Torvalds' keynote at the Open Source Summit, we attracted criticism for, um, quoting the project's own description from that page, saying how preliminary it was.

I don't have time to read through all the comments but, if there was anything I'd criticize in that article, it'd be the lack of mention of the much more mature rustc_codegen_gcc project which works by connecting up the existing rustc frontend to GCC rather than writing a whole new one in C++.

Aside from re-bootstrapping rustc from C++ (for which mrustc already exists and where Rust-GCC probably wouldn't do any better at keeping up with the self-hosted compiler's eager use of new language features), it should serve any need you might have better. (And it's not as if Rust-GCC intends to be a completely alternative implementation. They plan to reuse Polonius, the in-development third generation of rustc's borrow checker... written in Rust, which sounds, to me, like the biggest place for "accidentally baked implementation details into the language spec" to lurk.)

> That means it's a moving target for the team working on the GCC compiler to try to hit.

>

> So far, there have been three "editions" of the language, which the Rust book defines as follows:

And GCC and LLVM Clang had to implement "editions" named ANSI C, C99, C11, C17, and whatever C2x will be, plus Clang having to replicate whichever GNUxx "edition" the Linux kernel is written in.

What's your point?

Heck, I find it telling that C11 seems to be the point at which C became too complex for anyone but big names like GCC, LLVM, and MSVC to implement, because all the hobby and niche compilers seem stuck at C99.

> The Rust-on-GCC project isn't the only alternative Rust toolchain being worked on. MrustC, or Mutabah's Rust Compiler, is another, being implemented in C++ and which emits, as the project page puts it, "currently very ugly C, but LLVM/cretone/GIMPLE/… could work".

...and mrustc is already complete enough to serve its purpose of re-bootstrapping rustc to prove it free of trusting trust attacks (by producing a compiler that can then compile itself and get output byte-identical to the official builds) all the way up to rustc 1.54.0 despite the rustc codebase generally being eager to use new language features.

>There's also rustc_codegen_gcc, a work-in-progress GCC code generator that uses libgccjit.

And, again, it should be mentioned that it's much further along than Rust-GCC (which should be the main thing that matters to a project like the kernel) because it works by connecting GCC up as an alternative backend to the existing rustc frontend.

See https://blog.antoyo.xyz/ for status updates on that project.