March 2025 Monthly report

Overview

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

Project update

74 pull-requests were merged this month, with multiple internal compiler error fixes thanks to the fuzzing work done by Matthias Krüger, which helped expose multiple invalid code paths in the compiler. Thank you!

We also spent some time getting our mininum supported Rust version down to Rust 1.49 for our Rust components. As a reminder, Rust 1.49 is the version that gccrs currently targets, and getting our own Rust components compilable with this version also means getting closer and closer to gccrs compiling its own components - an objective we will pursue as soon as we are able to compile the Rust standard library. This also enables for more testing on less common systems, as certain versions of Darwin or Ubuntu still in use by our community only have access to older Rust installations.

We are still working on developing new features and upstreaming them in time for the GCC 15.1 release. The cutoff date for the branch is yet to be announced, but should happen soon. We have continued work on our milestones, and have spent a lot of time getting further and further into the compilation of core. This opened new issues on the project with our macro expansion and name resolution, which we quickly fixed in the last few weeks.

One of the focus of this month was adding support for the min_specialization feature, which you can learn more about here. In its current form, gccrs only supports a subset of min_specialization, which itself is a subset of specialization in general. We are required to support parts of this feature as it used in core to improve runtime performance in certain cases.

For example, the machinery responsible for implementing Iterator::zip (as a reminder, Iterator::zip enables you to tie together two iterators and advance them as the same time) lives in the core::iter::adapters::ZipImpl trait, whose definition looks like this:

// Zip specialization trait
#[doc(hidden)]
trait ZipImpl<A, B> {
    type Item;
    fn new(a: A, b: B) -> Self;
    fn next(&mut self) -> Option<Self::Item>;
    fn size_hint(&self) -> (usize, Option<usize>);
    fn nth(&mut self, n: usize) -> Option<Self::Item>;
    fn next_back(&mut self) -> Option<Self::Item>
    where
        A: DoubleEndedIterator + ExactSizeIterator,
        B: DoubleEndedIterator + ExactSizeIterator;
    // This has the same safety requirements as `Iterator::__iterator_get_unchecked`
    unsafe fn get_unchecked(&mut self, idx: usize) -> <Self as Iterator>::Item
    where
        Self: Iterator + TrustedRandomAccess;
}

If we keep reading through the file, we can see two implementations for this trait:

impl<A, B> ZipImpl<A, B> for Zip<A, B>
where
    A: Iterator,
    B: Iterator,
{ /* ... */ }

// and ...

#[doc(hidden)]
impl<A, B> ZipImpl<A, B> for Zip<A, B>
where
    A: TrustedRandomAccess + Iterator,
    B: TrustedRandomAccess + Iterator,
{ /* ... */ }

In one case, the implementation is more specialized and adds an extra bound - TrustedRandomAccess. Without specialization, these two implementations are ambiguous, as they contain similar bounds. But by using specialization, the core library is able to provide a default, safe and slower implementation of zip while also providing a fast one where possible, for example if the iterators support trusted random access, meaning it supports efficent and safe random index accesses.

The method next for these two implementations of ZipImpl thus look like the following:

impl<A, B> ZipImpl<A, B> for Zip<A, B>
where
    A: Iterator,
    B: Iterator,
{
    #[inline]
    default fn next(&mut self) -> Option<(A::Item, B::Item)> {
        let x = self.a.next()?;
        let y = self.b.next()?;
        Some((x, y))
    }
}

// and...

impl<A, B> ZipImpl<A, B> for Zip<A, B>
where
    A: TrustedRandomAccess + Iterator,
    B: TrustedRandomAccess + Iterator,
{
    #[inline]
    fn next(&mut self) -> Option<(A::Item, B::Item)> {
        if self.index < self.len {
            let i = self.index;
            self.index += 1;
            // SAFETY: `i` is smaller than `self.len`, thus smaller than `self.a.len()` and `self.b.len()`
            unsafe {
                Some((self.a.__iterator_get_unchecked(i), self.b.__iterator_get_unchecked(i)))
            }
        } else if A::may_have_side_effect() && self.index < self.a.size() {
            // match the base implementation's potential side effects
            // SAFETY: we just checked that `self.index` < `self.a.len()`
            unsafe {
                self.a.__iterator_get_unchecked(self.index);
            }
            self.index += 1;
            None
        } else {
            None
        }
    }
}

In the more specific method, the behavior is the same, but the implementation makes use of extra type information to provide faster runtime performance when selecting the next items to iterate on. With the work done this month, gccrs is now able to select these faster methods without producing an “ambiguous method resolution” error. While specialization is not used in Rust-for-Linux, it is important that we are able to resolve to the same methods as rustc when compiling code. This will also make for more optimized binaries and a faster kernel once we are able to compile Rust-for-Linux. In order to fully support min_specialization however, we would need to implement a new algorithm for deciding between two default functions and choosing the most specific one, which would require the development of a new decision tree and the associated algorithms. This is not required for core or Rust-for-Linux, and will thus be worked on at a later date.

Community call

We will have our next monthly community call on the 22nd 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

• format_args: Allow extraneous commas, improve safety PR3737
• nr2.0: Do not resolve modules this run if they are unloaded PR3736
• Handle doc comments in macros + fixes for invalid macro expansions in core PR3734
• Cleanup rust-gcc.cc by Andrew Pinski (20-03-2025) PR3721
• nr2.0: Adjust test issue-2812.rs PR3701
• nr2.0: Adjust test macro6.rs PR3700
• Fix const checking of enum discriminants PR3699
• fix: add check for null feature gate to display error properly PR3692
• nr2.0: Remove duplicate self visit PR3691
• gccrs: Fix ICE for reserved lifetime name PR3690
• gccrs: Fix ICE on raw reference PR3688
• gccrs: Fix ICE on invalid match arms PR3687
• Implement proper method resolution for min_{specialization} PR3685
• gccrs: Fix ICE when hitting invalid types for generics PR3684
• gccrs: Fix recusive type query and nullptr on type path PR3683
• gccrs: Fix ICE when there are 2 functions named main PR3682
• Nr2: fix missing labels PR3679
• Add base for handling #![feature(min_specialization)] PR3678
• install.texi: Mention Rust requirement for building gccrs PR3677
• gccrs: Fix ICE when doing shift checks on const decl PR3676
• gccrs: Fix ICE when resolving lifetimes without name PR3675
• nr2.0: Improve test script PR3674
• Fix error when evaluating an enum discriminant containing arithmetic operations PR3637
• gccrs: Fix SEGV when type path resolver fails outright PR3624
• gccrs: fix ice when setting up regions PR3623
• gccrs: fix crash in parse repr options and missing delete call PR3622
• gccrs: FIX ICE for malformed repr attribute PR3621
• gccrs: FIX ICE when working with HIR::BareFunctionType PR3620
• gccrs: Fix ICE in array ref constexpr PR3619
• Add ending newline to rust-macro-builtins-log-debug.cc PR3604
• nr2.0: Rename prelude to lang_prelude PR3603
• gccrs: Fix ICE during const expr eval on array expressions PR3602
• gccrs: Fix ICE when compiling path which resolves to trait constant PR3601
• gccrs: Give the builtin unit struct an actual locus PR3600
• gccrs: Fix ICE when doing method resolution on trait predicates PR3580
• gccrs: Fix ICE when compiling block expressions in array capacity PR3579
• gccrs: Add check for super traits being implemented by Self PR3578
• gccrs: Fix ICE when using super mid way though path PR3576
• gccrs: Fix ICE when array elements are not a value PR3575
• gccrs: fix unconstrained infer vars on generic associated type PR3573
• Fix core library test’s canonical path PR3572
• Lower raw string literals PR3562
• Fix validation of constant items PR3561
• nr2.0: Handle global paths PR3532
• Fix unresolved imports PR3529
• rust: Lower minimum supported Rust version to 1.49 PR3528
• nr2.0: Fix test macros/mbe/macro43.rs PR3527
• gccrs: support generic super traits recursively PR3522
• nr2.0: Fix test const_generics_3.rs PR3521
• Recognize #[track_caller] PR3520
• Modify multiple definition error PR3519
• nr2.0: Adjust indentifier expression handling PR3518
• Nr2: Add missing function to silence error PR3517
• nr2.0: Adjust visitors for struct expressions PR3516
• NR2: Fix path resolution canonical path in tests PR3515
• chore: refactoring rust_errorat “redefined multiple times” PR3513
• nr2.0: Fix StructExprFieldIdentifier handling PR3512
• nr2.0: Fix test self-path2.rs PR3511
• polonius: Vendor Rust dependencies PR3508
• ci: disable network PR3504
• Fix Error: Type or Const Parameters on Foreign Items PR3503
• gccrs: check for recursion trait cycle with bounds checks PR3501
• gccrs: Track defid on fntypes and cleanup PR3500
• Fix nr2 use declaration import PR3499
• nr2.0: Check compile/torture/*.rs tests PR3498
• Fix some small issues PR3497
• Fix nr2 as string ice (within foreverstack) PR3495
• testsuite: Add more testcases for cfg() in core PR3494
• nr2.0: Set the node id of the root node PR3490
• Parse and lower let-else statements PR3468
• Fix nr2 exhaustiveness PR3465
• Prevent duplicate resolution insertions PR3456
• Fix modules with same name as builtins causing ICE (#3315) PR3437

Contributors this month

• Ryutaro Okada (new contributor!)
• Matty Kuhn (new contributor!)
• Bhavesh M (new contributor!)
• Sri Ganesh Thota
• Owen Avery
• Sam James
• Liam Naddell

Overall Task Status

Bugs

Test Cases

Milestones Progress

Planned Activities

• Finish derive(PartialOrd) and derive(PartialEq) implementation
• Finish let-else compilation
• Upstream changes up to the release point

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.