Gccrs after libcore
There are a few reasons to want a GCC-based Rust compiler, he began. Many developers are working with GCC now, prefer it, and do not want to have to change to a different toolchain. Having multiple compilers helps to build confidence in the future of a language in general. There is also the list of architectures that GCC supports, but which LLVM does not.
There is an intermediate option in the form of rustc_codegen_gcc, a project that grafts the GCC code-generation layer onto rustc. But, Patry said, few people seem willing to use rustc_codegen_gcc; he was unsure why. And, in any case, that project does not fully address the problem of architecture support in the Rust standard library, which must be ported separately to each new architecture. So developers are still waiting for gccrs, which is progressing.
Recent work
A longstanding problem with gccrs has been name resolution; that is a complicated task in Rust, and gccrs was not able to handle all of the possible cases. Now, though, name resolution has been rewritten from scratch and imaginatively named "name resolution 2.0". This work is complete and enabled by default in gccrs, though there are still some details to work out.
![[Pierre-Emmanuel Patry]](https://static.lwn.net/images/conf/2025/cauldron/PierreEmmanuelPatry-sm.png "Pierre-Emmanuel Patry")
The project's development methodology has changed somewhat in the last
year, he said. The project's approach is, essentially, "find a random
problem, fix it, repeat". Recently, that approach has been focused on
being able to build libcore,
the Rust core library that is needed by all programs. That focus has been
good, helping the project to identify the highest-priority issues, but it
has also been slowing down progress recently. Fixing the building of
libcore is essentially a serial process at this point; one problem must be
dealt with before the next can be identified. So now, to increase
parallelism, the gccrs developers are starting to spread their focus again.
The plan for gccrs has long been to implement support for version 1.49 of the Rust language, which was released in 2020. Among other reasons, that version was chosen because it was the last before the addition of const generics to the language. But it turns out that libcore needs a lot of newer, not-yet-stabilized Rust features; the 1.49 version of libcore uses, among other things, const generics. The Rust developers often put pre-stabilization features into the compiler and use them internally, and that has happened here. For this reason, gccrs has ended up including a number of newer language features, even though 1.49 remains the target.
Work has also progressed on impl trait (also covered here), which enables the specification of generic types that implement a given trait. "Argument position impl trait" allows the type of a function parameter to be inferred at the call site; the actual type of a parameter is not visible to the called function, only the expected trait. More recently, work has been done on "return position impl trait", where functions can return an abstract type implementing a given trait.
There were a couple of Google Summer of Code students working on the project this year. The first worked on rest patterns — patterns in match statements that match the remainder of a structure. Progress was made, but some patterns remain unimplemented. The second student worked on moving the lint mechanism away from GCC's GIMPLE internal representation, which was unable to support generics, to the gccrs high-level representation, which is able to carry much more information about the source program.
One year ago, he said, the project was concerned about performance; it took the compiler 30 seconds to compile about 1,000 lines of macro-heavy code. Performance has been a relatively low priority for this project, which is still focused on just getting something working, but there was still some time to look for easy problems to fix. It turns out that the type-checking code was doing a bit more copying of data than was strictly necessary; working through five lines of code could result in over 65,000 extra copies. This problem has been addressed, and the compiler is much faster now.
Next steps
One of the next things to be worked on, Patry said, is the Drop trait, which functions as an object destructor. This feature is coming along, but is missing the necessary glue to recursively drop nested structures. There is also a need to implement the code that ensures that all references to an object are truly gone before invoking the trait. Fn traits, used by closures, are partially implemented in gccrs now. Handling of dyn traits, which support dynamic dispatching, is almost complete as well.
People often ask "when will gccrs be ready?", he said. It will be ready in one sense — building libcore, though perhaps not compiling it entirely correctly — by early 2026. Once that is done, the focus will shift to being able to build Rust for Linux; that will involve adding a number of newer features, the availability of which will be hidden behind a command-line option. Patry stressed that the project will not, initially, try to implement every feature added between 1.49 and the 1.78 version required by the kernel; only features actually used by the kernel will go in.
After Rust for Linux, the plan is to build the entire 1.49 standard library. There still is no plan to increase the target version; the focus is still on getting things working. Most of the features needed by the standard library are also needed by libcore, so this phase should go relatively quickly.
Last year, the project added a dependency on rustc to compile the Rust code used by the compiler itself. Many people dislike this dependency and would like to see it go away. Once the standard-library support is complete, though, the compiler should be able to bootstrap itself, allowing the eventual removal of the rustc dependency.
The step after that is to move toward version 1.80 (or later) of the language. There aren't that many language changes after 1.49 that should pose problems, he said. But support for features like trait upcasting and use<...> will take some work.
For some time, the gccrs project has had the goal of pushing its work upstream into the GCC trunk every two weeks. Instead, code has been pushed upstream only three times (so far) in 2025. The process has improved and things will get better, he said, but he can't guarantee a two-week cycle anytime soon. Equally problematic has been keeping up with upstream GCC, which was a painful and manual process. That work has mostly been automated and is happening regularly now.
Patch review is a problem, though. Upstream GCC developers are generally
unable to review Rust-specific patches, especially when they are sent in
batches of 200 or so a few times a year. These batches need to be split
into smaller, more frequent posts, but this work, he said, is not something
the project wants to force its contributors to do. Gccrs, it seems, has a
number of "very young
" contributors who are not really able to work
well with an email-based workflow; without care, those contributors will be
lost.
The GCC project in general has been experimenting with Forgejo, using a bot to email patches upstream in response to pull requests. Gccrs has been playing with a similar scheme out of its GitHub repository; contributors can work entirely within GitHub and not have to interact with the mailing lists to submit patches. I asked what happens when people on the mailing lists have comments about the posted patches; at that point, it seems, the contributor will still have to deal with email.
The gccrs developers think that the Forgejo experiment is a good one that
will widen the access to the project for contributors. It brings together
a lot of resources onto a single page and matches what developers are using
more widely; it is also free software, unlike GitHub, which is
"proprietary and awful
". But, he said, that experiment is still
exactly that: an experiment that could be removed at any time. Moving the
gccrs project from
GitHub would likely lose some contributors, and would leave behind a lot of
metadata that lives within the GitHub system. It would also complicate the
task of maintaining cross-references with the Rust repositories. Beyond
that, he said, GitHub functions as a sort of social network; leaving it
would reduce the gccrs project's visibility.
Thus, he said, gccrs is not considering making a switch in the short or medium term, even though gccrs developers are enthusiastic about the experiment.
Patry concluded there. I asked how many developers are working on the project now; he answered that there are two engineers working on it full time, and roughly ten in a sort of core team who contribute regularly.
All told, gccrs seems to be making better progress than might have been expected a year or two ago. It was a bit discouraging, though, to see this talk placed at the end of the conference and sparsely attended; one gets the sense that interest from the wider GCC community in Rust is not all that high. Given the role that proper Rust support could play in keeping GCC relevant in the coming years, one might expect to see that community show a bit more interest.
[Thanks to the Linux Foundation, LWN's travel sponsor, for supporting my travel to this event.]
| Index entries for this article | |
|---|---|
| Conference | GNU Tools Cauldron/2025 |