Towards GCC 15.1

Introduction

The aim of this document is to serve as semi-live engineering preview of what we aim to achieve for gccrs in the coming year(s), and in what timeline. What “semi-live” means is that we aim to update this document as we progress and close off milestones, which should hopefully reflect our progress in the coming months.

The shape of this document is very rough, as it served as a starting point to establish our Github milestones. We have used it as a way to estimate the time of each task, which allowed us to create a dependency graph and Gantt chart with expected deadlines as well as starting dates for each of the milestones.

This gives us a rough outline of when we expect the compiler to be able to be used as a general purpose compiler, or when we can start experimenting with gccrs for compiling the Rust parts of the Linux kernel, and other important milestones.

As a reminder, the main development focus for this year is the handling of correct Rust code, and more specifically the 1.49 version of the core crate. Once that is achieved, we will shift our focus towards compiling the alloc crate, which will enable us to start working towards the compilation of the Rust-for-Linux project.

For an updated version of the milestone’s completion rate, check out our latest monthly report which will include a table regrouping all of the milestones together.

Content

We need to prioritize and milestone-ize what is absolutely needed for compiling core and RfL. For example, Issue 2032 concerns invalid Rust code that should be checked against, but that is not present in either core or RfL as these two projects only contain valid Rust code - hence, it is low priority and will not appear on this document.

Rust for Linux

We want to be able to provide an experimentation platform for RfL developers. This means that the compiler may not be completely able to compile RfL, but at least able to be experimented with.

This requires core support.

core support

Supporting the entire core library is necessary in order to be useful for the RfL project, as well as the rest of the ecosystem. This will enable us to start looking at the alloc crate, another crate used by the RfL project, as well as the rest of std for regular userland Rust code.

Milestones

GCC 14.2

We will be able to add small changes to GCC 14.2, mainly non-technical ones. This milestone should only concern documentation changes, or other small non-technical items.

RfL unstable features

NOTE: Some of the required features are not used upstream ATM, so we might be able to reduce that list/split it in two

https://github.com/Rust-for-Linux/linux/issues/2

Some of the tasks listed above are not Rust language features but rather features used by the RfL project as a whole - things like command-line options for rustc, or functions in core.

We need to be able to support these functions, and to implement equivalent command-line options.

By grepping in the RfL codebase, it seems that not that many nightly features are actually used (as of 2024-05-13). An updated list for those unstable features can be found here

https://rust-lang.github.io/rust-project-goals/2024h2/rfl_stable.html

* this one may not be necessary as it is being replaced by other features

black_box hint function

At the moment, this function is implemented using the llvm_asm!() builtin macro, which we need to figure out how to handle in Inline assembly. Note that in later versions of the language, black_box becomes an intrinsic function - we need to be able to handle that properly as well.

Explicit generic argument with impl Trait in function signature

https://github.com/rust-lang/rust/issues/83701

This feature is disallowed in Rust 1.49, but required for RfL.

Generic Associated Types

https://github.com/rust-lang/rfcs/pull/1598

offset_of! builtin macro

#[cfg] handling - core 1.49

#[cfg] handling - RfL

There might be complex cfg invocations in Rust-for-Linux, so we will need to be able to parse and handle all of them properly. This milestone will be developped in time as it is hard to get visibility on the topic. However, our existing cfg-handling pass is pretty complete, so this should not take a lot of time - probably a month or so.

let-else

let-else is stable in Rust since 1.65, so much later than the Rust version we target. However, they are already in use in the RfL project: grepping for 'let .* else ' gives the following hits:

// rust/macros/paste.rs:29                
let Some(TokenTree::Ident(ident)) = tokens.next() else {
 
// rust/macros/helpers.rs:170
let Some(name) = toks.next() else {

This will require extensive modifications to the parser, AST, HIR, type system and codegen - so almost all steps of our compiler pipeline.

Note that the last issue in this table is about the let-else feature in general and concerns all of the issues mentioned above it.

Question Mark operator

NOTE: This milestone will probably grow as it is not well-researched yet.

The ? operator is used in core to propagate errors and for control flow. We need to desugar it properly (and probably to handle the Try family of traits as well).

lang items

for-loops

for-loops are required to support some of the functions implemented in core. We are running into issues with name resolution as well as type resolution to fully support them.

This will enable us to finally close Issue 682 regarding the blake3 algorithm.

Specialization

core requires some form of specialization to be present for optimization reasons. We need to be able to handle this subset of the feature, at least to select the proper trait methods that Rust expects. However, since specialization is used solely for optimization purposes, and that all implementations should be equivalent, we should be able to ignore specialized versions of a function and simply pick the most generic one, at least for core.

Inline assembly

This work will be done as part of a Google Summer of Code project.

With a start of the work around the beginning of June, I think we can have inline assembly implemented completely by the beginning of September. This feature should be usable by August.

Indexing/Slices

Iterators

There are issues around the various indexing and iterator traits defined in core which we need to investigate and fix. These are necessary for handling for-loops.

alloc parser issues

There are still parsing issues left to fix in order to completely compile alloc 1.49. We need to collect these issues precisely and fix them in time for 15.1.

There are no more parser issues for core 1.49 thanks to @Pierre-Emmanuel, so this milestone only concerns code needed by RfL and the standard library. As such, this milestone can be handled later in the year.

std parser issues

Issues in the parser when trying to compile std 1.49.

Unhandled attributes

Attributes used in core, alloc, std or RfL which we need to add handling for.

Macro expansion

Similarly, there are probably expansion issues when running the compiler on core 1.49 which will need to be addressed. They might however highlight other issues, such as name resolution, in which case they should not be part of this milestone.

Name resolution 2.0

We have two name resolution algorithm in the project.

• The “old” one is incomplete and cannot perform a correct name resolution.
  • Its structure is unsuited for rust.
  • It has several bugs and cannot even name resolve the requirements for our mini standard library.
• The new name resolution algorithm “name resolution 2.0”
  • Incomplete and not used by default

We need to fix the new name resolution algorithm and fix all regressions. Once complete we need to enable it by default. This milestone is extremely important, as we currently cannot name-resolve core 1.49 properly. All other core milestones are thus “dependent” on this one in order to compile core properly in its entirety, without singling out modules or code examples.

NOTE: Should we fix some bits in name resolution 1.0 in order to compile the mini standard library? Probably not but this means we need to default to 2.0 soon.

Typecheck

NOTE: This needs to be split into sub milestones one for each big category of typecheck bugs

Improve auto traits handling

auto traits are essential to Rust, as they mark very intrinsic functionality of the runtime. Linked to them are negative impls, which, while unstable, are important for the Rust language and used throughout core. We need to handle them properly and completely in our trait solver.

Improve Deref and DerefMut handling

These two traits are absolutely essential to the Rust programming language, but we currently run into some very specific and hard-to-debug issues with their implementation in core 1.49.

Remaining typechecking issues for core

Codegen

Borrow checking error improvements

Another GSoC project for this year, which aims to improve the user experience when running the experimental borrow-checking algorithm in gccrs.

Borrow checking

RfL Const Generics (as of 2024-05-13)

Grepping for '<.*const.*>' gives the following hits:

kernel/init.rs
1020:pub fn init_array_from_fn<I, const N: usize, T, E>(
1064:pub fn pin_init_array_from_fn<I, const N: usize, T, E>(
1333:    {<const N: usize, T: Zeroable>} [T; N], {<T: Zeroable>} Wrapping<T>,

kernel/workqueue.rs
 178:    pub fn enqueue<W, const ID: u64>(&self, w: W) -> W::EnqueueOutput
 271:pub unsafe trait RawWorkItem<const ID: u64> {
 315:pub unsafe trait WorkItemPointer<const ID: u64>: RawWorkItem<ID> {
 330:pub trait WorkItem<const ID: u64 = 0> {
 351:pub struct Work<T: ?Sized, const ID: u64 = 0> {
 360:unsafe impl<T: ?Sized, const ID: u64> Send for Work<T, ID> {}
 364:unsafe impl<T: ?Sized, const ID: u64> Sync for Work<T, ID> {}
 366:impl<T: ?Sized, const ID: u64> Work<T, ID> {
 435:pub unsafe trait HasWork<T, const ID: u64 = 0> {
 521:unsafe impl<T, const ID: u64> WorkItemPointer<ID> for Arc<T>
 538:unsafe impl<T, const ID: u64> RawWorkItem<ID> for Arc<T>
 566:unsafe impl<T, const ID: u64> WorkItemPointer<ID> for Pin<Box<T>>
 585:unsafe impl<T, const ID: u64> RawWorkItem<ID> for Pin<Box<T>>

It seems that the required const generics only concern “simple” types, e.g. u64 and usize. So unstable const generic features do not seem to be required.

The milestone will concern adding testcases for those functions and ensuring const generics are handled properly in those cases. It will also be a nice time for us to clean up our implementation and make sure the code is in a nice state.

main shim

This is not “required” for RfL or core, but it is for real user code.

Const generics 2

NOTE: What to do here? what do we need to add in Const Generics 2?

Frontend hooks for GCC plugins

Milestone link

Project link

GCC 15.1 top-level patches

• Build system improvements
• Anything else?
• Windows/MinGW patches?

These need to be done early so that they cannot be rejected for 15.1 due to lack of time.

NOTE: Add this to risk table?

Adapting the rustc testsuite

This GSoC project concerns the adaptation of the rustc testsuite in order to run it using gccrs as a compiler.

Testsuite issues

Issues raised by running the rustc testsuite under gccrs.

Milestone table

TODO

• Add existing issues to milestones for next year
• Create issues on repository for all tasks