Overview
Thanks again to Open Source Security, inc and Embecosm for their ongoing support for this project. 2026 Introduction Hi everyone! Welcome to our first monthly report of the year 2026! As our work starts again after the winter holidays, we wanted to take some time to outline what is shaping up to be a pretty significant year for gccrs, in a more candid way than the usual tone of these reports. The goal of this is for people interested in our project to know what to expect, how to support us, and what the project will focus on moving forward. We have recently been mentioned in LWN's "Predictions for the new year" article, which sparked some encouraging and supportive comments that we really enjoyed reading. The specific quote of the article is as follows: "The gccrs project will deliver a working Rust compiler" Wow! That's not a lot of pressure at all! But Jonathan is right - the goal is for gccrs to be able to compile the Rust parts of the Linux kernel in 2026. Preferably, before RustConf and EuroRust, so that we can make some noise about it. Now, that does not mean that you will be able to use a Linux kernel with the Rust parts compiled by gccrs (we do hope you try and report all of the interesting issues though). gccrs will still be experimental, and even though it should be able to compile the kernel, that does not mean the executable produced will be able to run correctly. For 2026, our goal is for gccrs to be able to mis-compile the kernel. There are things that we do not plan for gccrs to handle just yet, which may incur incorrect behavior in the produced binaries - which is to be expected from an experimental compiler. Thus begins a nine months long marathon to get the kernel compiling :) This time will also be a great opportunity to get in touch with more people on the kernel and Rust side to make sure that gccrs fits in in all the ways that is expected of the project. Regarding the upcoming GCC 16.1 release: while we are working towards getting the kernel working by the time it comes out, this might not happen. For people willing to experiment with compiling their kernel using gccrs, you will have to compile the project from scratch. We hope to get enough in GCC 16.1 so that gccrs is able to compile core, and can thus be used in embedded environments for #![no_std] Rust code. We hope you understand that playing catch up like this takes a long time, and that some problems only show up when compiling actual projects - not simple test cases. While we do have the advantage of knowing what is supposed to work, we run into different problems than if we were just trying to design our own programming language from scratch. Knowing how core works, what compiler tricks are required, how the crate is implemented, is not innate, and while the team is getting pretty good at it, we still have some work to do. Thank you once again for your continued support and involvment. 2025 was a very fun year for the project, and 2026 seems to be headed in the same direction, with even more interesting problems to fix. Project update For the last month of 2025, we have once again made good progress on our name resolution algorithm in the hopes of getting core further along our compilation pipeline. We have not necessarily focused on the kernel itself this month, as most of the team was away on vacation for half of the month. The entire early name resolution and macro expansion fixed-point is now complete for core, which is a massive milestone for the project - it is actually the reason why we decided to rewrite name resolution from scratch a couple of years ago. We are now able to handle all of the complex imports and exports in core, coupled with the extensive amount of macros used for various primitive implementations. This leads us to the second half of the problem, late name resolution, which is currently still not finished for core. This holiday season, we have fixed four massive bugs which impacted core as well as complex Rust crates. There are still a few issues with our late name resolution, namely around certain vectorized types and methods not being found, but nothing too drastic or hard to fix. Other technical improvements include the work done by our two interns, Lenny Chiadmi Delage and Lucas Ly Ba, who have greatly improved various lints in the compiler focused on correctness and safety. January marks our last month with them, and we will greatly miss them and their contributions! We will continue working on these late name resolution issues for the first few weeks of 2026, and will hopefully be able to quickly switch to our middle-end and backend issues for core - which there shouldn't be much of. Once name resolution passes, we will be able to split our focus between core and the kernel, figuring out what issues show up once the kernel correctly depends on core. As explained before, the goal is for gccrs to be able to compile core and the kernel before RustConf and EuroRust in September, two conferences where we hope to present the work done on the compiler these last two years. The CFPs for these conferences is almost open, which means we are also spending some of our time working on our abstracts. We want to maximize our chances of the talks getting accepted, as these two conferences could be the most important talks we've ever given for the project! Finally, our upstreaming is still going strong, as we are sticking to our schedule and uploading commits weekly. We are up to date with the latest GCC, which is also up to date with our development branch. Community call We will have our next monthly community call on the 12th of January at 10am UTC. You can subscribe to our calendar to see when the next one will be held. The call is open to everyone, even if you would just like to sit-in and listen. You can also subscribe to our mailing-list or join our Zulip chat to be notified of upcoming events. - Jitsi link - Calendar ID:7060a0923ffebd3cb52b1afef35a28ff7b64f05962c9af84c23b1847f1f5f...@group.calendar.google.com
- Google calendar link - iCal link Call for contribution - https://github.com/Rust-GCC/gccrs/issues/2500 - https://github.com/Rust-GCC/gccrs/issues/2376 Completed Activities - Sync with upstream (2026-01-03): d5743234731ecc62d889e297a7576561600da41d PR4351 - gccrs: Fix rogue macro error during lowering on expansion failure PR4347 - nr: Add better error to unresolved attribute macro PR4345 - Sync with upstream (2025-12-21): c65fdb6b03d9146ee9a1ffcfcbc689b004b2b463 PR4335 - Fix: #![cfg_(attr)(…, feature)]` not respected PR4334 - Make some general improvements PR4332 - gccrs: refactor string methods in HIR PR4331 - Sync with upstream (2025-12-10): 203d4dd09ba83121e447ce93ba98175b68d955f6 PR4328 - Check for deprecated attributes PR4327 - Follow up to #3212 PR4326 - Use the path location for MetaItemPathExpr PR4324 - Split the parser implementation into multiple files PR4322 - Sync with upstream (2025-12-01): 4d1bfc66f84de6b37b175a191cba8cdd552c4383 PR4320 - Improve feature handling PR4319 - Add missing test for lang item feature gate PR4318 - Remove match arm pattern vector to single pattern PR4297 - Implement unused mut lint PR4290 - Use tl::expected in the parser to avoid error state PR4288 - Implement unused assignments lints on HIR PR4285 - Implement unused variable checker on HIR PR4283 - gccrs:fix ICE with continue/break/return in while condition PR4270 - gccrs: fix parser error on parenthesised types PR4214 Contributors this month - Harishankar (new contributor!) - Ashwani Kumar Kamal (new contributor!) - Owen Avery - Lenny Chiadmi Delage - Lucas Ly Ba - Pierre-Emmanuel Patry - Arthur Cohen Overall Task Status Category Last Month This Month Delta ------------- ------------ ------------ ------- TODO 419 409 -10 In Progress 116 118 +2 Completed 1184 1194 +10 Bugs Category Last Month This Month Delta ------------- ------------ ------------ ------- TODO 198 194 -4 In Progress 55 56 +1 Completed 588 591 +3 Test Cases TestCases Last Month This Month Delta ----------- ------------ ------------ ------- Passing 10444 10470 +26 Failed - - - XFAIL 74 73 -1 XPASS - - -
OpenPGP_0x1B3465B044AD9C65.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
