GCC Front-End For Rust

Alternative Rust Compiler for GCC

View the Project on GitHub

February 2023 Monthly report

Overview

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

Milestone Progress

The number of contributions this month stayed extremely important, with a lot of new contributors and many existing contributors returning. The month of January, which was already impressive with around 50 pull-requests merged, got supplanted by February, where we saw around 80 pull-requests from more than a dozen people get submitted and merged!

We hope that everyone has a nice time contributing to the project, but we are aware that there might still be some rough edges for new contributors. Please feel free to reach out to let us know what could be improved!

This month, Pierre-Emmanuel spent some more time getting our build system to handle the new Rust libraries we will be bringing to the GCC project. He has also made significant strides on multiple libcore-related issues, namely on some features our parser lacked. Philip has spent a lot of time on iterators and for loops, bringing us closer and closer to supporting all of libcore 1.49’s intricacies and internal mechanics. The handling of for loops requires being able to compile a significant portion of libcore, which we are really excited about. Arthur spent some more time on name resolution and macros overall, finally bridging the gap between macro exporting and our metadata exports, which allows us to start pulling in public macros from external modules and crates.

Furthermore, the GCC project was accepted as a GSoC organization this year again. We have put together 4 project proposals for gccrs, for which you are welcome to submit a proposal! Philip and Arthur will be mentoring applicants together.

You can find these project ideas here on the GCC wiki, in the Rust frontend section.

You will be able to start submitting them on the 20th of March. In the meantime, feel free to come chat with us on Zulip and discuss them, or talk about new project ideas. We are open to all ideas, and are looking forward to your submissions!

Finally, gccrs will be present at Embedded World 2023 at the Embecosm booth. Feel free to come see us to chat about the project!

Community call

We had our monthly community call on the 6th of March. 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.

Completed Activities

Contributors this month

Overall Task Status

Category Last Month This Month Delta
TODO 211 198 -13
In Progress 43 40 -3
Completed 522 586 +64

Test Cases

TestCases Last Month This Month Delta
Passing 5483 5613 +130
Failed - - -
XFAIL 40 40 -
XPASS - - -

Bugs

Category Last Month This Month Delta
TODO 67 54 -7
In Progress 11 21 +10
Completed 227 265 +38

Milestones Progress

We are putting together milestones regarding projects such as libproc and will update the Milestone.

Note that the intrinsics milestone percentage on github is not representative: It shows a 69% completion rate, but does not take into account the tracking issues with dozens of unresolved items. Thus the percentage is computed using the sum of issues and tracked items done divided by the sums of issues and tracked items overall. Similarly, the Update GCC’s master branch milestone contains a tracking issue containing over 200 tasks. The percentage shown here takes this into account.

Milestone Last Week This Week Delta Start Date Completion Date Target
Data Structures 1 - Core 100% 100% - 30th Nov 2020 27th Jan 2021 29th Jan 2021
Control Flow 1 - Core 100% 100% - 28th Jan 2021 10th Feb 2021 26th Feb 2021
Data Structures 2 - Generics 100% 100% - 11th Feb 2021 14th May 2021 28th May 2021
Data Structures 3 - Traits 100% 100% - 20th May 2021 17th Sep 2021 27th Aug 2021
Control Flow 2 - Pattern Matching 100% 100% - 20th Sep 2021 9th Dec 2021 29th Nov 2021
Macros and cfg expansion 100% 100% - 1st Dec 2021 31st Mar 2022 28th Mar 2022
Imports and Visibility 100% 100% - 29th Mar 2022 13th Jul 2022 27th May 2022
Const Generics 100% 100% - 30th May 2022 10th Oct 2022 17th Oct 2022
Initial upstream patches 100% 100% - 10th Oct 2022 13th Nov 2022 13th Nov 2022
Upstream initial patchset 100% 100% - 13th Nov 2022 13th Dec 2022 19th Dec 2022
Update GCC’s master branch 71% 100% +29% 1st Jan 2023 21st Feb 2023 3rd Mar 2023
Final set of upstream patches 47% 70% +23% 16th Nov 2022 - 30th Apr 2023
Intrinsics and builtins 18% 18% - 6th Sept 2022 - TBD
Borrow checking 0% 0% - TBD - TBD
Const Generics 2 0% 0% - TBD - TBD
Rust-for-Linux compilation 0% 0% - TBD - TBD

Risks

The last remaining risk was for gccrs to not get merged in GCC 13 by us missing the stage deadline, but that is no longer the case.

Testing project

The testing project is on hold as we try and figure out some of the issues we’re running into with GitHub and our various automations around it.

Planned Activities

Detailed changelog

Generic Argument bindings

Recently we add support for the binding associated types syntax in generic arguments such as:

core::ops::Add<Output = i32>>

This syntax of Output=xyz allows the arguments of an associated type bound set the expected associated types expected argument to be. This means when we do bounds checking we need to ensure that when bounds match not only are they coherent as in are they actually implemented as well as any parent trait bounds, but are their expected associated types ok. So for example you might do something like this:

mod core {
    mod ops {
        #[lang = "add"]
        pub trait Add<Rhs = Self> {
            type Output;

            fn add(self, rhs: Rhs) -> Self::Output;
        }
    }
}

impl core::ops::Add for f32 {
    type Output = f32;

    fn add(self, rhs: Self) -> Self::Output {
        self + rhs
    }
}

pub fn foo<T: core::ops::Add<Output = i32>>(a: T) -> i32 {
    a + a
}

pub fn main() {
    foo(123f32);
}

This test case shows that we expected foo to take an Add trait bound with an output of i32 but in main we are passing an f32 which obviously returns an f32 for its add output. Which results in this error:

<source>:25:9: error: expected 'i32' got 'f32'
   13 |     type Output = f32;
      |     ~~~~ 
......
   20 | pub fn foo<T: core::ops::Add<Output = i32>>(a: T) -> i32 {
      |               ~~~~
......
   25 |     foo(123f32);
      |         ^~~~~~
<source>:25:9: error: bounds not satisfied for f32 'Add' is not satisfied
   20 | pub fn foo<T: core::ops::Add<Output = i32>>(a: T) -> i32 {
      |               ~~~~
......
   25 |     foo(123f32);
      |         ^~~~~~

see: https://godbolt.org/z/r6jn3aGjj