July 2025 Monthly report

Overview

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

Planned Activities

• Start working on try blocks and while-let loops
• Finish name resolution and macro expansion issues

Risks

We must establish the list of GCC-common changes we need, as we will have to send them upstream before the start of Stage 3 around November. This is the only risk which could incur further problems and prevent more gccrs features from landing in 16.1.