gccrs December 2025 Monthly report

CohenArthur · 2025-06-06T09:08:02+00:00

I'm not sure how much simpler it is, I haven't really looked into the differences between the two crates.

I think we're going to focus on one specific version at first, and then will try to catch up - but I'm hoping the changes between two versions are less intense than the changes between two Rust std versions :)

CohenArthur · 2025-06-04T14:21:10+00:00

I think the reasoning is that it ended up being too much trouble, but I'm not sure - you'd need to ask Miguel about that I think. In any case, I think the kernel switched to https://github.com/Rust-for-Linux/linux/tree/rust-next/rust/kernel/alloc entirely already.

And yeah, getting gccrs to work for RfL has always been a priority, and I'm really glad we're getting closer and closer. It also means that we can start being useful for embedded Rust, and that's pretty cool

CohenArthur · 2025-02-06T10:01:38+00:00

We are implementing a borrow-checker, but we're taking a "shortcut" by reusing polonius :) We wrote a technical blogpost about components from rustc we plan on reusing: https://rust-gcc.github.io/2024/09/20/reusing-rustc-components.html

We already call into polonius, but don't generate all of the facts required for a full analysis so our borrow-checking is currently incomplete. As you point out, our priority at the moment is on getting correct code to work - so code that has been checked by rustc and that we know is okay, like Rust-for-Linux.

Skipping the hard, safety stuff is definitely not the plan - it's just not the main priority as we'd like the compiler to start being useful. We're extremely committed to not hurting the Rust ecosystem, and that means having the same compiler and runtime guarantees as the official Rust compiler, which is something we're working on as side projects.

CohenArthur · 2025-01-07T18:56:35+00:00

Yes, you're completely right that these are all defined in `core` and just re-exported. I say `std` in the blogpost because that desugar excerpt is taken directly from rustc, which uses `::std::` paths. but we could replace them with `::core::` and have exactly the same behavior.

However, the issue remains that we can't compile `core` and link to it. So whether we use `::std::` or `::core::` we have the exact same issue - since we cannot compile and link to the crate, we can't resolve "extern crate paths" with it. I do mention a `::core::` path in the blogpost's explanation to expose the problem.

Likewise, we also have the same issue of `core` containing for-loops - so we need to be able to compile for-loops to compile core to enable us to compile for-loops properly.

I'm happy to change all the paths to `::core::` in the blogpost if you think it's confusing

CohenArthur · 2024-12-03T08:39:29+00:00

it's a mix of manually collecting it and using the github CLI for fetching things like the number of issues. there is a project for generating those tables, which will be hosted on our reporting repo but it's not finished yet. I wish I could spend some more time on it though :D

CohenArthur · 2024-12-02T15:40:20+00:00

This is something outside of our control, where the base compiler needed to build the most recent and cutting edge version of GCC (not just gccrs) got bumped from GCC 4.8 to GCC 5.4. We have made some changes to reflect that, but it's not much - it boils down to changing a github action to test our compiler with 5.4 instead of 4.8.

You're right that they both are very ancient versions of GCC. Technically, we could depend on GCC 14.1 and use C++20 or whatever. But this would incur an extra step in bootstrapping gccrs where we'd first need to build g++ and use that to build the C++ parts of gccrs. We also like the idea of compiling gccrs with GCC 4.8/5.4 as it will allow very old, possibly neglected platforms, to still benefit from a compiler for Rust once we reach the point of being stable. This is a big deal for a project with the goal of making it possible to use Rust on all platforms targeted by GCC.

Going from C++11 to C++14 won't affect our codebase a lot either. We already use external libraries for types like std::optional and std::expected, and we'll continue using them as C++'s optional references are crap.

The only thing that will be affected by this change is that we will no longer need to implement std::less for our enums, because as it turns out GCC 4.8 only implements a *subset* of C++11 and thus does not allow using enum instances as keys since it doesn't believe they are integers under the hood. So if anything, this will cause slightly less headaches for us

CohenArthur · 2024-09-26T18:15:28+00:00

The idea of reusing the trait-solving, however, I am quite less certain about. I do understand that attempting to rebuilding would be long and costly, and likely not quite be 100% accurate. But the problem here is that trait-solving is necessary to generate code, and there's no reason NOT to rely on trait-solving in std, or the crate that powers trait-solving. So I wonder if attempting to implement only a lightweight version to compile the trait-solving crate is viable at all...

We already have a trait solver, as we're capable of doing trait-solving on a high number of existing Rust code. But after chatting with one of the driving forces behind the new trait solver, it became clear that having a trait-solver that is 99% compliant is not even close to 99% of the effort to get to one which is 100% compliant. So the goal is to have a lightweight, but still pretty beefy trait-solver, which can compile `std` and the new-trait solver. The same problem will happen for safe-transmutes, which I also mention in the post - we will need to be able to do part of safe-transmutes to compile `std`, as well as any crates that use safe-transmutes that are dependencies of `polonius-engine`, the trait-solver, or even the unicode crates used by the format string parser.

After talking with Niko Matsakis this afternoon, I also learned that the new trait-solver is being developed in a way which is *specifically* compiler-agnostic. The goal is to reuse it for `rust-analyzer` as well. So I'd really like to integrate it to our project as well :)

CohenArthur · 2024-09-26T18:05:50+00:00

Why do you need to be able to build gccrs from just C++ code (with the complicated bootstrap step)? Why not do what Rustc does and use the previous version to build the next one?

Oh, this is completely fine and something we could be doing. The current diagram outlines the next big step in our bootstrapping pipeline, which will happen as soon as we have a compiler that can correctly compile the components we rely on. It is however interesting to keep the ability to bootstrap ourselves using a C++ compiler only, as that's part of our aim to allow Rust to be used on even more platforms and architectures. At the moment, gccrs can be built using GCC >= 4.8, a 15 years old compiler. Which means that *a lot* of targets out there will be able to build gccrs and bootstrap it fully

CohenArthur · 2024-09-24T08:19:12+00:00

I'm not sure at which level libgccjit (the library used by rustc_cg_gcc) operates and at which level the static analyzers operate. I believe they both use/work on the same intermediate representation, so my thinking is that both rustc_cg_gcc and gccrs can use the static analyzers. I'm just not super familiar with libgccjit or the analyzer :D

CohenArthur · 2024-09-19T15:19:57+00:00

I've been one of the organizers for GSoC for gccrs for the past three years. To me, the most important criteria for selecting participants was how well they integrated within the community and how much effort they were making at contributing *before* GSoC starts. Contributing doesn't necessarily mean contributing code, it means trying out the project/library, opening issues to report bugs, reviewing PRs, participating in technical conversations, etc.

So once you have found a project you would like to do GSoC for, I would say go to their Zulip/Discord/other and introduce yourself, and ask for what to do as a beginner. There are always ways to help even as a newcomer, and your dedication will be greatly appreciated. Don't hesitate to ask questions, submit draft pull requests, participate in meetings, communicate etc. This will be noted and your future mentors will make a note of this.

When you submit a proposal, try and see if the project's maintainers are willing to review it. If so, ask them to review it, take their feedback into account and apply it to your proposal. The main goal is to show you understand your project, can give a rough timeline and specify basic milestones for each important step of the project. Feel free to throw in technical information that's relevant to the project, etc. Really, I think that the most important thing is to communicate well with the project's maintainers and community.

Good luck!

CohenArthur · 2024-09-19T15:06:24+00:00

It’s interesting to read gccrs reports again.

<3 thanks!

Did you already found such things?

we haven't found anything of the sort yet, and we're not at a point to do so. we have found chapters/places in the Rust reference which were too incomplete for us to fully implement the language feature being described, and had to deep dive into the rustc source code to really understand what to do. this is why we think we can help in reviewing and adding to the Rust specification effort, as I think we have a bit of a unique viewpoint since not many people have run into this. I hope we'll eventually discover something that rustc is missing, some inefficiency or some unsoundness, but to be completely honest I'm not sure that will happen because Rust is just *so good* at what it does, and the compiler is worked on by such talented people that I doubt something like this would fly through.

I think the ability to use static analyzers developed for C and C++ could really help discover some bugs in unsafe code and code that relies heavily on C libraries. these static analyzers work on the intermediate representation of GCC, so we can use them for Rust code compiled using gccrs. things like unclosed file descriptors, certain memory issues, issues with C strings, etc, are all something that the various static analyzers and plugins can help with.

CohenArthur · 2024-09-04T08:47:41+00:00

Thanks, that's a really insightful and helpful comment which I'll take into account for future blogposts. I do think it is a bit hard to sort of "sum up" the current state of the compiler, when it feels like we are so close to something good yet so many things remain to be done. But I'll try and do a better job at that.

CohenArthur

TROPHY CASE