February 2025 Monthly report

Overview

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

Project update

We are still working hard to get as many features completed in time before the release of GCC 15.1. We have started preparing our branch for upstreaming patches to the compiler, and are in the process of improving our upstreaming and fork-updating process to make it more streamlined and enable upstreams to happen more often. This is taking quite a bit of time, but we are still on track regarding the milestones we set ourselves for GCC 15.1

We have started work on two major technical features required for handling Rust-for-Linux code: impl Trait types and let-else, two patterns used in the kernel and also often found in user code. Note also that impl Trait types are also used extensively in core, and are thus a requirement for properly handling the Rust standard library.

We have also continued work on our ongoing milestones, such as macro expansion fixes, our name resolution rewrite, and the handling of conditional compilation directives for core. We will then start working on a slimmed down version of specialization, as it is seldom used in core, but still required for properly compiling it.

Pierre-Emmanuel and Arthur will be attending Rust in Paris on the 14th of March, and we are hoping to meet lots of other French Rustaceans. Our next event will then be RustWeek in the Netherlands in May, and we will also be attending EuroRust in Paris where we hope to give a talk on the current state of gccrs.

A missing part of our macro expansion implementation was the handling of the $crate metavar, a special meta-variable used in macros which allows to refer to items defined in the same crate as the macro itself. When such a macro is used in an external crate, the metavar needs to be replaced by the crate-name and a scope resolution operator (::<crate_name>), but when it is used in the current crate, it can simply be replaced by the crate path segment.

In RfL’s inner implementation of its printing macros, this is used for making a call to a specific function: call_printk. This enables calling the macro from the kernel as well as from any kernel modules which uses the kernel as a dependency.

macro_rules! print_macro (
  ($format_string:path, false, $($arg:tt)+) => (
      match format_args!($($arg)+) {
          args => unsafe {
              $crate::print::call_printk(
                  &$format_string,
                  crate::__LOG_PREFIX,
                  args,
              );
          }
      }
  );
);

Another feature we need to handle for Rust in the Linux kernel is let else statements. let else statements look just like regular let statements with a pattern, with an extra diverging else block in case the pattern does not match. This example is taken directly from the kernel’s inner implementation for parsing some of its macros.

let Some(TokenTree::Ident(ident)) = tokens.next() else {
  panic!("expected identifier as modifier");
};

Functionally, the above code is similar to this one:

let ident = match tokens.next() {
  Some(TokenTree::Ident(ident)) => ident,
  _ => panic!("expected identifier as modifier"),
};

However, we cannot just desugar to a match expression despite the behavior being the same. The reason for this is that the following code typechecks:

let foo = match bar() {
  Some(value) => value,
  None => default_value,
};

While this one does not:

let Some(value) = bar() else {
  Some(default_value)
};

As the else block of a let else must be a diverging expression, whose type can only be !. So, something like a return expression or a macro invocation of unreachable!() or panic!().

Playground example

let Some(TokenTree::Ident(ident)) = tokens.next() else {
  panic!("expected identifier as modifier");
};

Finally, we also started working on handling opaque types/~impl Trait types~. This is required for many existing Rust programs and libraries, as it is a feature often used for refering to unnameable types or for more concise code. For example, when specifying complex bounds on a generic type, one can often use an impl Trait type instead:

fn foo<T: Iterator<Item = Bar>>(iterator: T) {}

// becomes

fn foo(iterator: impl Iterator<Item = Bar>) {}

More importantly, they are required for returning unnameable types, for example in the case of closures. We know that closures implement function-like traits, but they don’t have a type that is defined anywhere in source - their type is only known by the compiler. This makes it extremely hard to return them, as one is not quite sure what to put in their function’s signature. We can use the impl Trait notation to express the fact that what we are returning implements a certain trait that we know about (in the case of closures, often Fn, FnOnce or FnMut), and the typechecker will ensure that is the case.

#[inline]
fn flatten<U: Iterator, Acc>(
  fold: &mut impl FnMut(Acc, U::Item) -> Acc,
) -> impl FnMut(Acc, U) -> Acc + '_ {
  move |acc, iter| iter.fold(acc, &mut *fold)
}

In the case of Rust-for-Linux, this is also used to abstract complex memory operations used when dealing with self-referential types. The kernel offers a helpful pin_init!() macro for initializing self-referrential types, but the concrete type is not known by the user and thus cannot be named - all the user needs to know about is that this type implements the PinInit trait.

impl Example {
  fn new() -> impl PinInit<Self> {
      pin_init!(Self {
          c: 10,
          d <- new_mutex!(Inner { a: 20, b: 30 }),
      })
  }
}

Call for contribution

• https://github.com/Rust-GCC/gccrs/issues/2500

• https://github.com/Rust-GCC/gccrs/issues/2376

Completed Activities

• nr2.0: Make sure PathInExpression is default resolved PR3491
• nr2.0: Set the node id of the root node PR3490
• Reduce usage of rust-session-manager.h PR3464
• expansion: Correctly expand ``$crate` metavar PR3457
• Adjust unknown macro error message PR3455
• Adjust type path resolution error message PR3453
• nr2.0: Handle lang item type path segments PR3452
• nr2.0: Implement macro_use for modules PR3451
• Fix macro invocation in impl trait type bound PR3450
• Add derive(Hash)` expansion PR3449
• Remove some member functions from SingleASTNode PR3447
• Remove PathInExpression::get_patternnodeid PR3446
• Fix expansion of macros inside modules PR3445
• nr2.0: Fix issue with external crates PR3443
• Add comments to resolve_segments PR3442
• gccrs: initial setup for new OpaqueType to represent Impl types PR3441
• gccrs: Add name resolution and HIR lowering for ImplTraitType’s PR3440
• gccrs: improve error diagnostic for bad type-resolution in CallExpr PR3439
• Desugar error propagation PR3438
• gccrs: self paths are patterns but we dont have mappings for it PR3436
• gccrs: fix name resolution for generics where type param is declared later PR3435
• gccrs: fix unconstrained generics check to handle recursive generics PR3434
• gccrs: add diagnostic for E0229 no associated type arguments allowed here PR3431
• gccrs: enum type layout needs to respect the enum repr type PR3427
• gccrs: add variant_count intrinsic PR3426
• gccrs: add discriminant value intrinsic PR3425
• Get rid of duplicate interface #3396 PR3423
• gccrs: remove bad type checking diagnostic PR3421
• Add warning about default visitor usage PR3419
• nr2.0: Run DefaultResolver::visit on PathInExpression PR3418
• gccrs: Add test case to show issue is fixed PR3417
• nr2.0: Resolve paths which start with Self PR3416
• derive(PartialEq): Add partial implementation (hehe) PR3415
• gccrs: Fix compilation of trait-items which map to impl items PR3414
• gccrs: Fix bad generic substitution error on fn/adt types PR3413
• gccrs: Fix crash in privay reporter for placeholder types PR3412
• gccrs: coercion sites allow for type inference as well. PR3411
• gccrs: Fix ICE during path probe PR3410
• gccrs: Fix ICE when fn_once and fn_onceoutput lang item is not defined PR3409
• nr2.0: Remove accidental copies of resolver PR3408
• Add derive(Default)` PR3399
• inline-asm: Fix some warnings PR3393
• Desugar for-loops in the AST PR3392
• hir-dump: Fix more segfaults in the HIR dump PR3316
• Add type check on if-expr PR3306
• Fix bug in type resolution of paths PR3277
• Resolve instances of TypePath more accurately PR3220

Contributors this month

• GS-GOAT (new contributor!)
• Benjamin Thos
• Owen Avery
• Marc Poulhiès
• Thomas Schwinge
• Philip Herron
• Pierre-Emmanuel Patry
• Arthur Cohen

Overall Task Status

Bugs

Test Cases

Milestones Progress

Planned Activities

• Finish derive(PartialOrd) implementation
• Finish let-else implementation
• Start working on RfL related milestones
• Start working on specialization

Risks

We have now entered Stage 3 of GCC development, and all of the patches we needed to get upstreamed have been upstreamed. The risk that were outlined here are no longer present, and we are focusing on getting as many features implemented and upstreamed as possible.