Thanks again to Open Source Security, inc and Embecosm for their ongoing support for this project.

Project update

The first major news this month is the acceptance of our talk “Compiling the Linux kernel with gccrs” for RustConf 2026! Pierre-Emmanuel and Arthur will be going to Montreal, Canada, and look forward to meeting many of you! We have also submitted the same talk to EuroRust.

In terms of project management, we have decided to organize our current milestones into greater milestones to better reflect how useful the compiler will be. These overarching milestones are, so far, “embedded Rust compiler”, “Rust for Linux compiler” and “General purpose compiler”. This aims to reflect the fact that gccrs will soon be usable as a compiler for embedded Rust programs, which will only depend on core and crates depending on core. Once this is achieved, we will be iterating on top of this compiler to support the alloc crate as well as all of the Rust-for-Linux crates, which will enable GCC to compile the Linux kernel in its entirety. These can be further split in at least two - compiling software and creating a proper executable - for example, we may have a compiler able to handle embedded software, but which does not insert the necessary Drop calls, hence resulting in incorrect behavior. This is particularly important for the kernel, as types such as mutexes often have complex side effects as part of their Drop implementation. Not being able to release a mutex in programs compiled with gccrs would have particularly bad consequences, but being able to mis-compile the kernel is still an important milestone!

Indicating the target GCC version does not accurately reflect the state in which the compiler will be for that version. Our goal is to focus on these overarching milestones, rather than having a specific set of features in time for a specific GCC version. If you would like to use the latest gccrs features, you will need to build the compiler from source or use one of the releases we will put out on our Github page.

In terms of technical news, the compiler is now able to handle more kernel crates, with compiler_builtins being added to the list this month, and Pierre-Emmanuel focusing on the kernel’s ffi crate with only a few issues to resolve. We have also added an equivalent to rustc ‘s -Zcrate-attr command line option, which enables passing attributes when invoking gccrs. This is particularly helpful for our friends fuzzing the compiler, as gccrs now properly handles - and requires - the #![no_core] nightly attribute to compile code without depending on core. For name resolution, we have once again had to rework our internal data structures and handling of path resolution, as we realized that path resolution must first be done in the types namespace, regardless of which namespace we are trying to resolve a path in. This is due to imports and modules always being inserted in the types namespace. While the changes are simple, they have consequences to much of the codebase and require multiple refactoring to many of our visitors.

Finally, the deadline for GSoC proposals has passed - we have received 7 proposals this year and are currently reviewing them. They are once again of really high quality, and we thank every applicant who has submitted one :)

Community call

We will have our next monthly community call on the 27th of April at 9am 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: 7060a0923ffebd3cb52b1afef35a28ff7b64f05962c9af84c23b1847f1f5f894@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

• Fix ICE in unused var when we hit unit const type PR4518
• Add cttz and cttz_nonzero support PR4511
• Replace usages of `chainon` PR4508
• Strip down 1.0 resolver PR4506
• Delete macro attribute input PR4505
• rust: Fix ICE in function_{setparameters} PR4501
• gccrs: Fix ICE caused by TypeCheckBase::parse_reproptions PR4500
• Improve unit struct matching PR4499
• Fix glob import all ICE issue PR4498
• Remove redundant expand visitor overloads PR4497
• gccrs: Add new test cases for old issues PR4494
• Sync with upstream (2026-03-18): 1c73a21caf2dc83ced30f10076a682ea26e1ba71 PR4491
• Deduplicate some functions within PointerVisitor PR4489
• Accepts `compiler<sub>builtins</sub>` and `no<sub>builtins</sub>` attribute. PR4488
• Use pretty printer instead ofcall to open_memstream PR4487
• testsuite:Add a testcase for setup_{associatedtypes} PR4485
• Add ability to inject inner attributes from CLI PR4484
• Add enum items to value namespace as well PR4480
• Squashing local commits PR4468
• Intrinsic: Add `ctlz` and `ctlz<sub>nonzero</sub>` intrinsics PR4467
• Add no_std to builtin attributes PR4466
• Sync with upstream (2026-03-05): 0970bb8565616f61c6b7a7dd0edbc829b0064703 PR4464
• enforce function qualifier order PR4463
• feat: Implement `no<sub>core</sub>` feature gate check PR4462
• Fix match arm scope PR4460
• Intrinsic refactor PR4459
• Disambiguate identifier and path patterns PR4455
• gccrs: Fix 128-bit non-decimal integer literal saturation PR4454
• intrinsic: Add bswap intrinsic PR4452
• resolve: Fix ICE on ambiguous glob re-exports PR4451
• Prevent error emission with multiple wildcards PR4450
• rust: Explicitly instantiate FFIVec<Piece> template PR4446
• lint: Fix ICE on error_marknode in unused variable linter PR4438
• Improve path resolution PR4428
• expand: Add error check if derive has wrong item PR4359
• nr1.0: Remove support in checking phases PR4108

Contributors this month

• Mohamed Ali (new contributor!)
• Egas Ribeiro (new contributor!)
• Ahmed Said (new contributor!)
• Philipp Gesang (new contributor!)
• Hritam Shrivastava (new contributor!)
• Enes Çevik (new contributor!)
• Islam Imad
• Jayant Chauhan
• Harishankar
• Marc Poulhiès
• Owen Avery
• Pierre-Emmanuel Patry
• Arthur Cohen

Overall Task Status

Bugs

Test Cases

Milestones Progress

Here is the list of overarching milestones gccrs is currently targeting. We’ll use the acronym in the following milestone tables, in the column named “OA Milest.”.

Thanks again to Open Source Security, inc and Embecosm for their ongoing support for this project.

Project update

We have submitted an abstract to the RustConf call-for-papers, where we hope to present various interesting compiler stories about our journey towards core and compiling the Linux kernel. If accepted, Pierre-Emmanuel and Arthur will be looking forward to meeting everyone in Montreal in September. gccrs will also be at Embedded World in Nuremberg, so feel free to drop by and talk about the project!

Work during the month of February has been a bit slower, between professional travel and holidays. Nevertheless, Pierre-Emmanuel kept chipping away at getting certain Rust-for-Linux crates to compile, namely by reworking our attribute handling to allow more unstable features to be processed by gccrs. This meant reworking our pipeline once again, in order to split the cfg-stripping into two passes, much like we split name resolution into multiple passes last year.

For the work on core, we are now one import resolution issue away from getting to typechecking. We hope to fix this particular import in the coming weeks, and to keep progressing on other middle-end core issues.

We have started receiving interest from potential Google Summer of Code students, which is always heartwarming - we look forward to your contributions and proposals as the application date grows closer.

Community call

We will have our next monthly community call on the 17th of March 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: 7060a0923ffebd3cb52b1afef35a28ff7b64f05962c9af84c23b1847f1f5f894@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

• testsuite: Add test case for macro invocation missing body PR4449
• Add no_std attribute PR4447
• Sync with upstream (2026-02-14): 3a1bb1b70d017e4816650ed42d316accf2d93944 PR4439
• expand: Fix ICE on unimplemented RustcEncodable/Decodable derives PR4437
• ast: Fix missing location info in derive macros PR4435
• Remove `ProcMacroInvocLexer` PR4430
• gccrs : TypeCheck : Enhance missing fields error message PR4429
• parser: Fix rogue null pointer in null_{denotationpath} PR4427
• Improve feature collection and permit macro attribute input PR4425
• refactor: cleanup macro invoc PR4423
• parse: Fix ICE when using ‘dyn’ without trait bound PR4421
• parser: Fix ICE in AnonConst when expression parsing fails PR4420
• util/attributes: Fix ICE on bare #[deprecated] attribute PR4419
• Make `AST::Crate` final PR4418
• parser: Fix segfault in parse_{arithmeticorlogicalexpr} PR4417
• ci: fix send email workflow in case of large commit log PR4416
• derive: Implement reconstruct_path helper for cmp PR4395
• derive: Implement make_{qualifiedcall} helper PR4394
• Add wrapper class for automatic node cloning PR4350

Contributors this month

• Maulik Barot (new contributor!)
• Islam Imad (new contributor!)
• Jayant Chauhan
• Marc Poulhiès
• Harishankar
• Owen Avery
• Pierre-Emmanuel Patry
• Arthur Cohen

Overall Task Status

Bugs

Test Cases

Milestones Progress

Planned Activities

• Finish bug fixing on last complex core import
• Continue investigating Rust-for-Linux crate issues

Thanks again to Open Source Security, inc and Embecosm for their ongoing support for this project.

Project update

This beginning of the year was quite productive, with 41 pull-requests merged and numerous core problems discovered and addressed.

Our work on getting the kernel to compile is focused on the crates surrounding the main kernel crate. Pierre-Emmanuel has also been focusing on the numerous nightly unstable features used by the kernel, as gccrs will need to support them rather quickly. On a related note, one nightly feature we have implemented this month - but which is not essential to the kernel - is #![no_core]. gccrs now properly tries to link your Rust program with core, which since we cannot compile core yet, means all of our testsuite has to opt out of that linkage using the #![no_core] attribute. Unfortunately, this commit was so big that the changelog for it was rejected by the mailing list’s spam filter. Heh.

In other news, Pierre-Emmanuel updated the GCC wiki with project ideas for this year’s Google Summer of Code: https://gcc.gnu.org/wiki/SummerOfCode%C2%A0

Feel free to propose any project you’d be interested in working on! Please join our Zulip group chat in order to start discussing with the team if you plan on applying for GSoC.

On a final technical note, one of the issues discovered with core this month was an interesting edge-case in our import resolution algorithm we had failed to consider:

Our naive approach to import definitions was to directly insert the ID of the node that the import would resolve to. For example, in the following example,

mod foo { // Definition ID 1
    fn bar() {} // Definition ID 2
}

use foo::bar;

fn main() { // Definition ID 3
    bar();
}

We’d “replace” the import by a direct insert of Definition ID 2, and have the call to bar directly resolve to the function instead of resolving to the import. This is fine in most cases, and went unnoticed for a long period of time.

mod foo { // Definition ID 1
    fn bar() {} // Definition ID 2
}

use foo::bar; // Resolved to Definition ID 2, insert Definition ID 2

fn main() { // Definition ID 3
    bar(); // Resolved to Definition ID 2
}

For the most part, resolving to a reference to a definition or to the definition itself does not make a difference - the proper function gets called, typechecked, and everyone is happy. However, imports must act as a proper definition point, just like functions or modules. The correct way to resolve the above example is as follows:

mod foo { // Definition ID 1
    fn bar() {} // Definition ID 2
}

use foo::bar; // Resolved to ID 2, Definition ID 3

fn main() { // Definition ID 4
    bar(); // Resolved to ID 3
}

Consider this example:

use crate::intrinsics::{self, abort, is_aligned_and_not_null, is_nonoverlapping};

/* snip */

#[lang = "align_offset"]
pub(crate) unsafe fn align_offset<T: Sized>(p: *const T, a: usize) -> usize {
    use intrinsics::{
        unchecked_shl, unchecked_shr, unchecked_sub, wrapping_add, wrapping_mul, wrapping_sub,
    };

    /* snip */
}

Here, the second import within the align_offset function directly points to crate::intrinsics::self as a definition, and must be understood this way. But the import does not contain any function definitions, it merely points to the module which contains them. This means that we must rework how our name resolution algorithm works for itself, and for the output it produces for the rest of the compiler, as later passes do not care about whether something is a definition or a reference to a definition - they only want to work on the actual modules, types and functions.

Up until this point, our name resolution worked with an internal structure that was also its output for later passes - a simple hashmap linking each usage-point to its definition-point:

HashMap<Usage, Definition> usage_map;

With Usage and Definition simply being newtype-patterns for a NodeID, our internal ID structure for our AST nodes.

struct Usage(NodeId);
struct Definition(NodeId);

One possible modification is to modify the Definition type to allow them to become references to other ~Definition~s:

struct Usage(NodeId);
enum Definition {
  ImportOf(NodeId), // A use import
  Actual(NodeId), // Literally anything else that is a definition
}

This transforms our simple map into a graph, which we can then traverse at the end of name resolution to turn it back into a regular map - essentially flat-mapping it for later passes. This approach also allows us to do import loop detection, something we had not given much thought about previously as it is not essential for code-gen.

An issue with this implementation is that when inserting usage-points in our usage_map, we must know whether or not the NodeId that we resolved to in our NameResolutionCtx ribs is an import, or an actual definition. This has multiple ramifications and requires multiple changes to our internal name resolution structures, while also increasing their memory usage. Thankfully, we can easily avoid much of these changes thanks to one trick - if a Definition is also present in the map as a key, then it must mean that it is an import!

By traversing the map recursively as a graph and checking if each definition is also present as a key, we can easily avoid a lot of code churn and still produce the output expected by later compiler passes.

Community call

We will not have a community call this month as most of the team will be traveling. 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.

• Calendar ID: 7060a0923ffebd3cb52b1afef35a28ff7b64f05962c9af84c23b1847f1f5f894@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

• util/attributes: Fix ICE on bare #[deprecated] attribute PR4419
• ci: fix send email workflow in case of large commit log PR4416
• Reduce node id sharing PR4408
• Implicitely inject `extern crate core` PR4407
• ast: Fix module path resolution for sibling modules in root PR4406
• Detect macros with duplicate metavariable bindings PR4405
• name resolution: fixes resolution through modules PR4401
• Implement type check & codegen for HIR::StructPatternFieldTuplePat PR4400
• expand: Refactor field expansion and add documentation PR4398
• backend: Factor out asm operand chaining PR4397
• derive: Factor out Eq trait path generation PR4396
• gccrs: replace unreachable with sorry_at PR4391
• util/attributes: handle #[export_name] on static items PR4390
• util/attributes: error on malformed #[export_name] input PR4389
• Handle `export_name` attribute on functions PR4385
• gccrs: add non upper case globals lint PR4382
• gccrs: add non snake case lint PR4381
• gccrs: fix ice on let else expession PR4378
• Sync with upstream (2026-01-10): 00b6346d5374efab8dabbf99d2647ad69b1df706 PR4371
• testsuite: Adds test from issue 1245 PR4369
• testsuite: Adds test from issue PR4366
• Unused label lint PR4365
• Adds test from issue 1210 and correct error thrown PR4363
• ICE in get_dereferencedexpr, at rust/ast/rust-expr.h:435 PR4362
• gccrs: Fix ICE in insert_associatedtraitimpl due to recursion PR4361
• gccrs: add redundant semicolon lint PR4360
• util/attributes: Error on malformed lint attributes PR4358
• util/attributes: error on malformed #[link_section] input PR4357
• util/attributes: Check that #[target_feature] is only used on unsafe … PR4356
• util/attributes: Error on #[repr] applied to functions PR4355
• util/attributes: error on malformed #[no_mangle] input PR4354
• util/attributes: error on malformed #[link_name] input PR4353
• util/attributes: Fix/target feature malformed 4233 PR4349
• gccrs: Fix rogue macro error during lowering on expansion failure PR4347
• Add proper prelude imports PR4346
• forever-stack: Display depth in debug string PR4343
• gccrs: Fix empty struct constructors causing ICE during type checking PR4342
• Improve attribute validation Rust-GCC/gccrs#4235 PR4339
• ast: Add new GlobContainer class and use it PR4337
• Improved Expr parser errors PR4330
• name-resolution: Add std/core prelude resolution PR4149

Contributors this month

• Jayant Chauhan (new contributor!)
• Mason (new contributor!)
• Marc Poulhiès
• Harishankar
• Zhi Heng
• Lenny Chiadmi-Delage
• Lucas Ly Ba
• Owen Avery
• Pierre-Emmanuel Patry
• Arthur Cohen

Overall Task Status

Bugs

Test Cases

Milestones Progress

Planned Activities

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: 7060a0923ffebd3cb52b1afef35a28ff7b64f05962c9af84c23b1847f1f5f894@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
• Marc Poulhiès
• Pierre-Emmanuel Patry
• Arthur Cohen

Overall Task Status

Bugs

Test Cases

Milestones Progress

Planned Activities

Thanks again to Open Source Security, inc and Embecosm for their ongoing support for this project.

Project update

We have made good progress on compiling Rust-for-Linux with a first few PRs aimed at compiling Generic Associated Types. These types are unstable in Rust 1.49, and not present in core, but required for compiling the kernel crates. Regarding core, we have made progress on multiple name resolution issues and are now going much further in the pipeline. Only a few late name resolution issues remain, which we intend to fix shortly.

Our upstreaming process is now well ironed out, with weekly upstreams to GCC. This has led to an increase in reviews and interactions from the GCC side of the community which is very welcome! Having a more regular upstream schedule also helped with fixing some bootstrapping issues more quickly, which were introduced due to changes in the C++ frontend.

We are busy working away at the issues for Rust-for-Linux, and hope to be able to compile the kernel soon. We will try to present this work at multiple conferences in 2026, and we hope to have some good news! The goal is for the Rust front-end of GCC 16.1 to be able to compile the kernel and most 1.49 Rust code, and we are on track to complete this objective.

Community call

We will have our next monthly community call on the 8th of December 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: 7060a0923ffebd3cb52b1afef35a28ff7b64f05962c9af84c23b1847f1f5f894@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

• Improve feature handling PR4319
• Add missing test for lang item feature gate PR4318
• Remove non leaf errors PR4317
• Remove non-leaf error message in delimited tt PR4315
• gccrs: Fix comment typos in rust-macro-expand.h PR4314
• Correct spelling of ‘mentionned’ PR4313
• Fixes PR 122886: Initialize uninit boolean PR4312
• Remove non-leaf parsing failure error PR4310
• Sync with upstream (2025-11-25): fb9b614c675f66a7979a5f37ef60f32fab73abdd PR4307
• ci: add pull-request URL in commit emails PR4306
• #[lang] not feature gated PR4304
• Stop an infinite loop at EOF PR4303
• ci: refactor ccpp workflow PR4299
• Sync with upstream (2025-11-18): c48c6c0a50e45735783fc3a626a54e4a9c6bd36f PR4295
• gccrs: Add support for initial generic associated types PR4292
• gccrs: Fix `compile<sub>floatliteral</sub>` not compiling negatives properly PR4287
• ci: fix reference check PR4286
• ci: use variable instead of secrets for regular settings PR4284
• Sync with upstream (2025-11-12): 6947098a34ccc2f64ff52de88a136bc438091c10 PR4281
• ci: drop macos build PR4280
• gccrs: fix segfault on empty doc attribute PR4271
• gccrs: fix cfg attribute without parentheses error PR4264
• README: Fedora: Add `gcc`, `gcc-c++`, `cargo`, and `awk` PR4255
• gccrs: fix segfault in clone_pattern w macro PR4217
• gccrs: add error check if derive has wrong item PR4211
• Improve feature handling PR4082
• Add derived set to collect derived nodes. PR4047
• Create `LocalVariable` PR3862

Contributors this month

• Jonathan Wakely (new contributor!)
• Andrew V. Teylu (new contributor!)
• Osama Albahrani (new contributor!)
• Lúcio Boari Fleury (new contributor!)
• Owen Avery
• Pierre-Emmanuel Patry
• Marc Poulhiès
• Raiki Tamura
• Zhi Heng
• Lucas Ly Ba
• Lenny Chiadmi-Delage
• Ryutaro Okada

Overall Task Status

Bugs

Test Cases

Milestones Progress

Planned Activities

• Finish debugging core
• Continue collecting issues for Rust-for-Linux milestones
• Work on RfL issues

Thanks again to Open Source Security, inc and Embecosm for their ongoing support for this project.

Project update

We have started experimenting with compiling Rust-for-Linux, as planned in our last monthly reports, and we are happy to report very few issues apart from the ones related to requiring a functional core crate. We then created a new Rust-for-Linux milestone to gather all the missing functionality required for compiling the Rust parts of the kernel, and are still collecting issues.

Work on this will continue in parallel with the last few reminaing bugfixes for core. However, due to other Embecosm projects, Pierre-Emmanuel and Arthur did not have enough time in November to complete these few remaining bugs.

In other news, our two french interns are progressing really fast and will soon begin contributing to complete milestones for certain unhandled features required for Rust-for-Linux and further existing Rust code. They are very proficient and greatly help the team with the issues they tackle. For now, they are focusing on non-critical parts of the pipeline such as emitting warnings in certain conditions and fixing Internal Compiler Errors.

We have ironed out our upstreaming processes and now rebase gccrs on top of trunk regularly. Similarly, it is really easy for us to update trunk with our latest gccrs changes, which we are currently sending upstream once a week. This caused a few pain points when bootstrapping due to existing issues in the C++ frontend, but they are now resolved.

Thanks to the work from Marc Poulhies, our CI now sends emails to the GCC Patches mailing list for each commit merged in our development repository on github. This makes it easy for GCC hackers to interact with our Rust frontend and review patches as they come in. We have been testing the system for a month now, and Marc has ironed out the kinks, meaning it will be deployed on the 10th of November after a message explaining the steps on the GCC mailing lists.

Community call

We will have our next monthly community call on the 17th of November 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: 7060a0923ffebd3cb52b1afef35a28ff7b64f05962c9af84c23b1847f1f5f894@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

• gccrs: Fix segv in errors in type checking an impl item PR4274
• gccrs: Support generic constant impl items PR4273
• gccrs: Fix const generics handling on array types PR4272
• gccrs: fix error multiple cfg predicates PR4268
• gccrs: fix cfg attribute error with literal predicate PR4266
• gccrs: fix segfault with empty cfg attribute PR4263
• gccrs: Add support for binding const generic values to paths PR4253
• Sync with upstream (2025-10-31): 468f8a3df1cd9e63b38cd4855926e9507b916fd0 PR4251
• gccrs: Fix ICE with non-trailing const defaults PR4250
• Sync with upstream (2025-10-27): 9e10fc177be25e5430e72a5c55ce7a36c45562c3 PR4248
• gccrs: Add minus sign compilation for LiteralPattern PR4247
• gccrs: Fix negative bounds in `RangePattern` being handled incorrectly PR4243
• gccrs: Fix ICE on enum in tuple struct pattern PR4241
• Update tuple pattern type-check to attempt to continue resolving items after size error PR4239
• Fix ICE for repr attribute malformation PR4238
• gccrs: make invalid inner attributes show error PR4237
• ci: stop using pull_request event, use push PR4224
• gccrs: fix inner attr derive doesn’t show error PR4218
• gccrs: fix segfault on exported macro PR4215
• Bump clang-format version to use in CONTRIBUTING.md PR4208
• gccrs: fix ICE on missing pattern in while loop PR4207
• gccrs: fix ICE in TyVar constructor PR4206
• gccrs: Emit error when tuple-indexing on non-tuples PR4205
• ci: refactor conditional parts PR4202
• gccrs: Refactor TyTy::ConstType into separate types PR4199
• fix: early return for module file error in AST parsing PR4151
• Improve macro expansion for `libcore` PR4053

Contributors this month

• Lucas Ly Ba (new contributor!)
• Lenny Chiadmi-Delage (new contributor!)
• LowR (new contributor!)
• Lishin (new contributor!)
• elle
• Vishruth Thimmaiah
• Zhi Heng
• Marc Poulhiès
• Owen Avery
• Pierre-Emmanuel Patry
• Philip Herron
• Arthur Cohen

Overall Task Status

Bugs

Test Cases

Milestones Progress

Planned Activities

• Finish debugging core
• Continue collecting issues for Rust-for-Linux milestones
• Work on RfL issues

Thanks again to Open Source Security, inc and Embecosm for their ongoing support for this project.

Project update

Most of the time this month was dedicated to preparing and attending three conferences: Oxidize in Berlin, Kangrejos in Oviedo and GNU Cauldron in Porto. Pierre-Emmanuel and Arthur also started working on another project for Embecosm, thus reducing the time spent on gccrs this month.

Oxidize was a nice experience and a good way to meet with some people using Rust in the embedded industry. We were able to present the project to many people who had not heard of it, and show the advantages of using the GCC static analyzers on unsafe Rust code.

Kangrejos was a great way for Pierre-Emmanuel to meet with a lot of folks working on the Linux kernel. A lot of them expressed interest in our progress, and a few mentioned their personal requirement for sticking with a GCC toolchain for compiling the kernel.

In Porto for Cauldron, a lot of GNU folks were interested in the frontend’s experimental status and the projects’ roadmap. There were comments about removing the dependency on cargo and rustc, which we are currently working towards with our goal of getting the standard library to compile under gccrs.

On that point, the entirety of core was added as a testcase to our testsuite - we are slowly but surely getting it to go through more and more passes of our pipeline. There is currently one bug left for our entire pipeline to pass, which concerns the resolution of const items associated with built-in types, such as i8::MAX.

After communicating with the GCC release managers, we have also worked on implementing a new CI process whose goal is to send emails to the GCC mailing list for each commit merged in our development repository. This will allow GCC developers to review patches as they are merged upstream, instead of seeing them in batches every week when we upstream them.

Community call

We will have our next monthly community call on the 15th of October at 9am 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: 7060a0923ffebd3cb52b1afef35a28ff7b64f05962c9af84c23b1847f1f5f894@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

• ci: yet another fix for the conditionnal steps PR4197
• ci: fix step condition PR4196
• Add doc attribute checking on traits PR4195
• Fix malformed path segfault in attributes PR4194
• ci: fix early exit PR4193
• Add support for lowering rest patterns present in struct patterns to HIR. PR4192
• ci: handle empty commit list PR4191
• ci: adjust again the workflow for sending emails PR4190
• ci: don’t do cover letter, don’t group by PR PR4189
• ci: new workflow for sending emails after merging a PR PR4184
• gccrs: Fix ICE where we expect a num enum variant PR4183
• gccrs: Add error diag for self params on plain functions PR4182
• gccrs: Fix ICE on copied array expressions PR4181
• gccrs: Remove old hack from resolve operator overload PR4180
• gccrs: fnptr types can hold onto generic params so it needs to handle substs PR4179
• Metavar segfault PR4178
• gccrs: Fix ICE for invalid const capacity expression handling PR4177
• Test `libcore` PR4176
• Import `stdarch 1.49.0` PR4175
• Improve `FFIOpt` PR4174
• gccrs: Fix ICE handling division by zero in const eval PR4172
• Remove `AST::TraitItemConst` PR4170
• Protect from errors in alternate pattern parsing PR4169
• gccrs: Fix ICE with invalid const expression PR4150
• tests: added extra parens compile test PR4137
• Sync with upstream (2025-09-08): 4eb12ddd32d53ef55c2bd9bb03db057f096fff8f PR4136
• Implement `TokenCollector::visit(AST::FormatArgs&)` PR4135
• gccrs: track abi and unsafety on fnptrs for proper type checking PR4132
• gccrs: Revert “nr1.0: Remove support in expansion phase” PR4130
• gccrs: Revert “gccrs: Remove the template parameter PR4129
• gccrs: get rid of more clones in unify path PR4128
• gccrs: remove docker github workflow PR4127
• gccrs: Remove the template parameter so clang format stops barfing this PR4126
• Add test to confirm Rust-GCC/gccrs#3922 fix PR4125
• Add test to confirm Rust-GCC/gccrs#3924 fix PR4124
• nr1.0: Remove `EarlyNameResolver` PR4123
• ci: Bump commit to merge in arm64 ci PR4121
• Unify path-to-type handling in `Late` resolver PR4113
• nr1.0: Remove chunks of resolution phase PR4110
• Create subdirectory `checks/errors/feature` PR4107
• Implement compilation support for rest patterns in tuple struct patterns PR4102
• Improve ExpandVisitor’s completeness PR4099
• Vendor `libcore 1.49` PR4060
• Handle `link<sub>name</sub>` attribute PR4031

Contributors this month

• elle (new contributor!)
• Magnus (new contributor!)
• Zhi Heng
• Marc Poulhiès
• Owen Avery
• Pierre-Emmanuel Patry
• Philip Herron
• Arthur Cohen

Overall Task Status

Bugs

Test Cases

Milestones Progress

| Milestone | Last Month | This Month | Delta | Start Date | Completion Date | Target | Target GCC | |———–|————|————|——-|————|—————–|——–|————|

Planned Activities

• Finish debugging core
• Start experimenting with the kernel’s Rust code

Thanks again to Open Source Security, inc and Embecosm for their ongoing support for this project.

Project update

The month of August was focused on bug fixing for building core, once again. We identified some issues in our macro expansion and reworked our ExpandVisitor, a piece of code we had originally written 3 years ago which contained some shortcomings and would not expand macro invocations in all places required. We implemented a new visitor to visit nodes from their container, and potentially reseat their pointer - which fixed a lot of the issues and increased the completeness of the compiler. We then transformed all of our mutating visitors into visitors inheriting from this container visitor, which resulted in a cleaner codebase and a more correct front end.

Google Summer of Code also came to an end, with both our students Ryutaro Okada and Zhi Heng successfully completing their projects and earning top scores in their final evaluations. It was a joy to work alongside them on their projects, and we hope to see them contribute in the future.

As a reminder, our current objective is to get gccrs to a state where it can compile the Linux kernel’s Rust parts. The Rust-for-Linux project does not depend on the entire Rust standard library (std), but only on core - like a lot of Rust embedded projects. However, because the project wants to benefit from all of Rust’s functionalities, they are reimplementing parts of the standard library using the kernel’s memory allocator - this enables Rust kernel module developers to use types such as Vec<T>, or String. As such, the milestones we worked on this summer are aimed at two objectives:

1. Compile Rust’s core library, as it is the sole dependency of the Linux kernel’s Rust crate
2. Compile the Rust kernel crate

In order to do this, we had to implement some new Rust features over the summer: namely, try blocks and while-let loops, both used in core and within the kernel. The kernel makes use of more recent Rust features that are not present in the version we target, so we must implement them as well - for example, the offset_of macro.

Our first objective is the kernel’s alloc crate, a reimplementation of parts of the Rust std crate responsible for implementing dynamically allocated types. Thanks to the work of our contributors over the summer, we were able to implement all of the required language features mentioned above. We are now debugging a few remaining bugs in our name resolution and macro expansion passes.

The next two weeks of work on the project will be focused on these bugs, and the last two weeks of the month of September will be solely dedicated to compiling the Linux kernel’s alloc crate.

We are currently interviewing two interns who would contribute to the project for the period of September to January - we are currently designing milestones for them, so that they may contribute meaningfully to the project while gaining work experience within our company Embecosm SAS.

Finally, we will also be present at three major conferences in September:

• Oxidize in Berlin, Germany
• Kangrejos in Oviedo, Spain
• GNU Cauldron in Port, Portugal

Pierre-Emmanuel and Arthur will be giving talks at these three venues and we hope to meet with everyone interested in the project!

Community call

We will have our next monthly community call on the 8th of September at 9am 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: 7060a0923ffebd3cb52b1afef35a28ff7b64f05962c9af84c23b1847f1f5f894@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

• gccrs: Fix segv when handling invalid array capacities PR4120
• More const generics development PR4119
• Get rid of TyTy::BaseType can_eq interface PR4118
• Unify path-to-type handling in Late resolver PR4113
• Recognize rustc_allow_const_fn_unstable PR4111
• nr1.0: Remove chunks of resolution phase PR4110
• nr1.0: Remove support in expansion phase PR4109
• Implement missing var decl binding & read-only checker cases for TuplePatternItemsHasRest PR4106
• Emit error on lonely self use declaration PR4103
• Do not dump the AST if the parser emit errors PR4101
• Separate strip information from internal state PR4100
• Avoid std::unique_ptr<std::string> in Token PR4097
• gccrs: Refactor AST Patterns that hold multiple pattern items PR4096
• Remove Parser::parse_tuple_index_expr_float PR4095
• nr1.0: Remove support in privacy checker PR4094
• nr1.0: Remove support in pattern checker PR4093
• nr1.0: Remove support in borrow checker PR4092
• nr1.0: Remove support in rust-session-manager.cc PR4091
• Eagerly expand format_args macro PR4089
• ci: Fix arm64 ci PR4088
• Remove Parser::parse_path_in_expression_pratt PR4087
• Partial eq fn field PR4084
• Expect identifier subpatterns to be non-alt PR4083
• gccrs: fix ICE for empty enum variant PR4081
• Add AST::PointerVisitor PR4079
• gccrs: fix ICE by skipping invalid (non-FNDEF) candidates PR4078
• Reject empty cfg_attr PR4077
• Handle patterns in macro expansion PR4076
• nr2.0: Fix ChangeLog entry PR4075
• Improve libformat_parser FFI PR4074
• Fix Self macro and partial macro invocation parsing null check PR4073
• Finish up subpattern codegen support for identifier patterns PR4072
• Wildcard use declaration PR4070
• Replace old read-only checker with new one. PR4069
• CfgStrip AST nodes marked with #[test] PR4067
• Collect lang items after expansion PR4066
• Remove #[simd_test] support PR4065
• Improve handling of non-final path segments PR4063
• gccrs: Implement rest pattern support for slice patterns PR4062
• Fix Macro builtins asm clobber infinite loop PR4061
• gccrs: fix ICE in convert_tree for tuple destructuring with ref PR4059
• Allow early resolution to use the language prelude PR4058
• Detect failure to match an ident metavariable PR4057
• Add checks to ExpandVisitor PR4052
• gccrs: Fix ICE on exclusive_rangepattern lowering PR4049
• Exclude some inline assembly test PR4048
• Misc fixes in headers PR4045
• Improve handling of AttrInputLiteral PR4044
• Sync with upstream fa099f248e2462ecd5ab8b0cadd348aaf11bb093 PR4043
• Recognize rustc_args_required_const attribute PR4042
• Remove undefined behavior with static_cast PR4041
• Handle attributes in expression macros PR4040
• gccrs: Refactor HIR::PatternItem class and its derivatives PR4039
• Explicitely create empty vector PR4029
• Add offset_of!() evaluation PR4021
• Make AttributeParser rely more on Parser PR4018
• ci: Bump from macos-13 to macos-15 PR4001
• Implement readonly checker on HIR PR3881
• Fix ICE when trying to compile enums with non-const discriminants. PR3681
• Fix Error Code for Attempted to call something which isn’t a function nor a method. PR3496

Contributors this month

• Zhi Heng
• Ryutaro Okada
• Lishin
• Marc Poulhiès
• Owen Avery
• Pierre-Emmanuel Patry
• Philip Herron
• Arthur Cohen

Overall Task Status

Bugs

Test Cases

Milestones Progress

Planned Activities

• Finish debugging core
• Start experimenting with the kernel’s Rust code

Thanks again to Open Source Security, inc and Embecosm for their ongoing support for this project.

Project update

Our two GSoC students are progressing nicely on their projects and are both ahead of schedule. Zhi Heng’s work is allowing us to handle some complex pattern matches present in core, which the compiler would previously ignore - while Ryutaro’s contributions are adding more complex warning checkers while removing previous false positives. Thanks to them, the compiler is getting more correct, and gets closer and closer to real Rust code.

Speaking of this, this month marks an important milestone for gccrs: One of our earliest “real-code” milestone was an implementation of SipHash as is present in core: Link. This algorithm relies on an important amount of code from core, and we have been trying to compile it for multiple years. With Philip’s recent work on fixing typechecker issues, the module now works and is being compiled properly.

Overall, our progress on core is great and things are moving fast. We have completed the two milestones mentioned in last month’s report, try blocks and while-let loops, which allows us to continue moving forward with core. We have also completed the work package on the offset_of!() builtin macro, which marks our first Rust-for-Linux specific feature - as the macro does not exist in the Rust 1.49 standard library.

This means that our goal of experimenting with compiling the kernel at the end of the summer is on track.

1. try blocks

   The desugar for try blocks is interesting as it ties in with the desugar for the ? operator to prevent an early return from the enclosing function instead of the current block.

   In Rust 1.49, the common desugar for the ? operator is as follows:

   fn foo() -> Result<i32, ()> {
       let a = bar()?;
   
       Ok(15i32);
   }
   
   // becomes
   
   
   fn foo() -> Result<i32, ()> {
       let a = match Try::into_result(bar()) {
           Ok(value) => value,
           Err(err) => return Try::from_err(From::from(err)),
       };
   
       Ok(15i32);
   }
   

   As explained in last month’s report, the desugar for try blocks is as follows:

   try {
     <stmts>;
     <expr>
   }
   
   // becomes
   
   {
     <stmts>;
     ::std::ops::Try::from_ok(<expr>)
   }
   

   However, if we desugar the ? operator inside of a try block…

   fn foo() -> Result<i32, ()> {
       let a: Result<i32, ()> = try {
           bar()?;
   
           14i32
       };
   
       a
   }
   
   // becomes
   
   fn foo() -> Result<i32, ()> {
       let a: Result<i32, ()> = {
           match Try::into_result(bar()) {
               Ok(value) => value,
               Err(err) => return Try::from_err(From::from(err)),
           };
   
           Try::from_ok(14i32)
       }
   
       Ok(15i32);
   }
   

   …we can easily see how this would cause an early return from the function instead of the block, should the bar function call return an error. This is not the desired behavior, so the desugar must be able to handle short-circuiting from the enclosing try block instead.

   // expected desugar
   fn foo() -> Result<i32, ()> {
       let a: Result<i32, ()>  = 'try_label {
           match Try::into_result(bar()) {
               Ok(value) => value,
               Err(err) => {
                   break 'try_label Try::from_err(From::from(err));
               }
           };
   
           Try::from_ok(14i32)
       }
   
       Ok(15i32);
   }
   

   We cannot yet handle this “complex” desugar, which would require some changes to our desugaring infrastructure to keep some context when desugaring the ? operator. However, all of the try blocks in core 1.49 only use the simple form of try { <expr> }, which makes our job easier!

Community call

We will have our next monthly community call on the 11th of August at 9am 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: 7060a0923ffebd3cb52b1afef35a28ff7b64f05962c9af84c23b1847f1f5f894@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

• Fix object copying issue causing pointer inconsistency PR4038
• Avoid including rust-parse-impl.h in rust-parse.h PR4037
• Catch parse failure in parse_path_meta_item PR4036
• gccrs: Add test case showing method resolution with const-generics PR4035
• gccrs: Remove more calls to the old TyTy::BaseType::can_eq interface PR4034
• gccrs: Ensure we track the const generic substitution on the param mappings PR4033
• Fix uninitialized data in default constructors PR4032
• Retrieve token stream before vector move PR4030
• gccrs: Fix ICE during const eval of const capacity PR4026
• Add initial support for const generics PR4025
• Remove warning for unused self parameter PR4024
• Fix AttrInputMacro operator= overloading. PR4023
• Add offset_of!() evaluation PR4021
• Error message field member was not properly updated PR4019
• gccrs: Add rest pattern support for AST::SlicePattern PR4017
• Parse expression instead of literal in attributes PR4016
• Fix infinite loop with missing comma PR4015
• Fix semicolon after some namespace PR4013
• Inline assembly expressions PR4012
• nr1.0: Remove rust/typecheck support PR4011
• Add HIR::OffsetOf node PR4010
• Add OffsetOf AST node and offset_of!() parsing PR4005
• Desugar while-let loops PR4000
• Dispatch for-loop desugar properly PR3999
• gccrs: Implement compilation for SlicePattern matching against SliceType scrutinee PR3998
• Handle easy try-block desugar PR3997
• Handle IfLetExprConseqElse in DefaultResolver PR3996
• desugar: Add desugar dispatch for all desugars PR3994
• ast: Visit block labels if they are present PR3993
• gccrs: fix bad monomophization of generic paths - GOAL TEST CASE SIP HASHER WORKS! PR3992
• Specialize ExpandVisitor::expand_macro_children PR3989
• gccrs: return error node when this fails during constexpr case PR3988
• gccrs: Fix ICE with duplicate root item main function PR3987
• gccrs: Add test case to show issue is fixed PR3986
• gccrs: Add initial support for deffered operator overload resolution PR3985
• gccrs: Implement compilation for SlicePattern matching against ArrayType scrutinee PR3981
• gccrs: Reject loop in const/static context PR3980
• Improve parsing of simple paths PR3979
• gccrs: Add size checking to SlicePattern PR3913
• gccrs: Add test case showing all derives working on enum PR3912
• gccrs: Add test case to show issue is fixed PR3911
• gccrs: Add test case to show we emit better errors now PR3909
• gccrs: add test case to show issue is fixed PR3907
• gccrs: Fix ICE when handling bad constructor PR3901
• gccrs: Fix cast rules logic to try simple casts then fall back to coercions PR3900
• gccrs: Fix bad bounds checking for PartialOrd PR3899
• nr2.0: Check before visiting a for-loop’s label PR3895
• Resolve enum glob imports PR3894
• gccrs: Fix ice with invalid borrow expression PR3891
• Use MacroInvocLexer in AttributeParser PR3890
• gccrs: Do proper const folding during typechecking for array capacities PR3889
• Fix narrowing of Loan (size_t) into LoanId (uint32) PR3888
• Basic SlicePattern type checking PR3887
• Parse deferred const generics PR3886
• attributes: Add #[test] and #[simd_test] PR3884
• Change enum to enum class PR3878
• Remove Late visitor override for StructStruct PR3873
• Allow format_args to accept a raw string literal PR3872
• Load modules during CfgStrip phase PR3871
• Parse try expressions PR3870
• Remove reinterpret_cast usages in DefaultASTVisitor PR3869
• Sync with upstream 0d52a736a3856871761c89fefa59c2ff39f3a5f8 PR3860
• ast: Check before visiting a while-let’s label PR3797

Contributors this month

• Zhi Heng
• Ryutaro Okada
• Lishin
• Marc Poulhiès
• Owen Avery
• Pierre-Emmanuel Patry
• Philip Herron
• Arthur Cohen

Overall Task Status

Bugs

Test Cases

Milestones Progress