May 2024 Monthly report

Overview

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

Project update

We took some time this month to put together a document outlining the future of the project, like we had done last year. This document allowed us to establish smaller milestones, and to create a dependency graph in between these milestones. This, as well as an estimate of the time to complete for each issue, allows us to put together a Gantt chart which gives us start and target dates for each of the milestones. The purpose of this document is to evolve as time passes, and to reflect on our progress around the release of GCC 15.1, in one year of work.

To establish this document, we spent multiple hours painstakingly compiling each module of the core and alloc crates, hacking around the missing imports and dependencies in order to go as far as possible into the compiler pipeline, in the hope of unearthing new issues with the compiler. Because we attempted to compile each module separately, imports were not handled properly and we had to re-define huge chunks of the core library each time, making the progress very slow. However, as the high number of issues opened this month will show, this work is proving to be worthwile and gives us a clearer picture of the situation for our objectives of compiling the Rust standard library and the Rust-for-Linux project.

Speaking about Rust-for-Linux (RfL), Miguel Ojeda and Arthur had a great conversation regarding the state of the compiler and future goals of the Rust language concerning the kernel. For example, RfL no longer needs its own fork of the alloc crate - meaning that once we are able to catch up and compile the Rust standard library, we should have no issues providing this dependency to RfL. Furthermore, one of the goals of the Rust project for 2024 is to enable RfL to compile using a stable compiler, which should help us when catching up to the Rust version the kernel expects, as it will drop requirements for nightly features we might not have implemented.

Regarding GSoC, we are very impressed with the work done by our students so far. As they all had important commitments, such as internships or exams, they chose to start working on their project early and have done oustandingly. We are looking forward to more progress and we can’t wait to show you the cool features they are building.

On the technical side of things, we have started progressing towards the next milestones already. Internal compiler attributes are being handled, work has started on fixing some bugs discovered in our support of negative trait implementations (used in quite a few places in core 1.49), parser improvements are being worked on for alloc and std, and as usual, a lot of code is being cleaned up and improved continuously. Our GCC build system patch has now been reviewed, and the review comments adressed - meaning that upstreaming will start again shortly, and that GCC’s trunk will be in sync with our development repository. We are also working towards getting documentation in for GCC 14.2, which should release in the next few months.

Community call

We will have our next monthly community call on the 17th of June 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

• Issue 3001: Generic arguments are not disambiguated on error propagation expressions

Our error propagation expressions (expressions which use the question mark operator, of the form <expr>?) are currently forgotten in many of our AST visitors. As a result, there are unexpected cases when it comes to various parts of the compiler pipeline handling them. In that particular case, the function call’s generic arguments are not disambiguated - the compiler does not know if it needs to be handling a generic type, or a const generic value. You will need to add handling to our name resolution pass for these error propagation expressions. It would be helpful to look at the current generic disambiguation to start figuring out where it is called from, and where you need to call it.

Completed Activities

• Corrected access specifiers PR3043
• Remove cstddef header from rust-fmt PR3011
• Visit constant items without expressions properly PR3005
• Add call and method call default visitors PR3004
• Allow rustc_const_stable and rustc_const_unstable PR3003
• Make gccrs recognize negative_impls_ PR3002
• Allow matching on non-enum ADTs PR2978
• Remove unnecessary SIDE_EFFECTS_/READONLY macros PR2977
• Remove unused Context parameter for some backend methods PR2973
• Make most lookup return an optional PR2972
• Rework hir map to make it’s API more confortable to work with. PR2969
• Removed obsolete objects PR2968
• libformat_parser_: Lower minimum Rust version to 1.49 PR2964
• Handle structs as scrutinee for match expressions PR2958
• Remove system include in gcc/rust/typecheck/rust-hir-type-check.h PR2924
• Improve handling of ConstantItem during name resolution 2.0 PR2900
• Borrowck tests and build PR2889

Contributors this month

• mazin (new contributor!)
• Jasmine Tang
• Kushal Pal
• Jakub Dupak
• Owen Avery
• Nobel Singh
• Mael Cravero

Overall Task Status

Test Cases

Bugs

Milestones Progress

Planned Activities

Risks

Detailed changelog