December 2024 Monthly report

Overview

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

Project update

This month of development was focused on three major milestones of compiler development: auto traits, built-in macros and for-loops, which are all important in order to compile core 1.49 and later, the Rust-for-Linux project.

The most widely known auto traits in Rust may be Send and Sync, which are used all throughout the Rust standard library to indicate thread-safety. As such, these traits are often used in trait-bounds to restrict sharing behavior to thread-safe objects:

trait Foo {
    fn foo(&self);
}

struct Safe;

// We cannot send pointers safely between threads
struct NonThreadSafe(*const i32);

impl Foo for Safe { fn foo(&self) { } }
impl Foo for NonThreadSafe { fn foo(&self) { } }

fn take_foo(foo: &(dyn Foo)) {
    foo.foo();
}

fn take_thread_safe_foo(foo: &(dyn Foo + Send + Sync)) {
    foo.foo();
}

fn main() {
    let s = Safe;

    let i = 15;
    let n_s = NonThreadSafe(&i as *const i32);

    take_foo(&s);
    take_foo(&n_s);

    take_thread_safe_foo(&s);
    take_thread_safe_foo(&n_s);
}

which errors out with the following:

   Compiling playground v0.0.1 (/playground)
error[E0277]: `*const i32` cannot be shared between threads safely
  --> src/main.rs:31:26
   |
31 |     take_thread_safe_foo(&n_s);
   |                          ^^^^ `*const i32` cannot be shared between threads safely
   |
   = help: within `NonThreadSafe`, the trait `Sync` is not implemented for `*const i32`, which is required by `NonThreadSafe: Sync`
note: required because it appears within the type `NonThreadSafe`
  --> src/main.rs:8:8
   |
8  | struct NonThreadSafe(*const i32);
   |        ^^^^^^^^^^^^^
   = note: required for the cast from `&NonThreadSafe` to `&dyn Foo + Send + Sync`

error[E0277]: `*const i32` cannot be sent between threads safely
  --> src/main.rs:31:26
   |
31 |     take_thread_safe_foo(&n_s);
   |                          ^^^^ `*const i32` cannot be sent between threads safely
   |
   = help: within `NonThreadSafe`, the trait `Send` is not implemented for `*const i32`, which is required by `NonThreadSafe: Send`
note: required because it appears within the type `NonThreadSafe`
  --> src/main.rs:8:8
   |
8  | struct NonThreadSafe(*const i32);
   |        ^^^^^^^^^^^^^
   = note: required for the cast from `&NonThreadSafe` to `&dyn Foo + Send + Sync`

Part of our pipeline was lacking support for these automatic trait bounds, which now enables us to build this code properly. Two missing features remain for properly handling these special bounds:

1. Additional trait bounds can only be automatic traits

We have to restrict the usage of additional trait bounds to auto traits exclusively, as rustc does:

fn takes_only_clone_copy_and_fromstr(a: &(dyn Clone + Copy + FromStr)) {}

will give out the following error:

error[E0225]: only auto traits can be used as additional traits in a trait object
  --> src/main.rs:16:55
   |
16 | fn takes_only_clone_copy_and_fromstr(a: &(dyn Clone + Copy + FromStr)) {}
   |                                               -----   ^^^^ additional non-auto trait
   |                                               |
   |                                               first non-auto trait
   |
   = help: consider creating a new trait with all of these as supertraits and using that trait here instead: `trait NewTrait: Clone + Copy + FromStr {}`
   = note: auto-traits like `Send` and `Sync` are traits that have special properties; for more information on them, visit <https://doc.rust-lang.org/reference/special-types-and-traits.html#auto-traits>

https://doc.rust-lang.org/stable/error_codes/E0225.html

We must add additional logic to our typechecker in order to check for these bounds, and make sure that the additional bounds we resolve to only refer to auto traits - otherwise, error out with an appropriate error message. This isn’t a terribly difficult feature to add, but it does require a bit of experience with our type system.

1. Implementing Send and Sync properly

Finally, we must implement the Send and Sync traits properly, and auto traits in general, so that they are applied automatically unless you opt out of it. One major difficulty comes from having to automatically opt-out types that contains other opted-out types, like in the following example:

#![feature(auto_traits)]
#![feature(negative_impls)]

auto trait MegaAuto {}

struct S;

impl !MegaAuto for S {}

struct S_Wrap(S);

fn take_mega_auto(a: &dyn MegaAuto) {}

fn main() {
    let a = S;
    let b = S_Wrap(S);

    take_mega_auto(&a);
    take_mega_auto(&b);
}

which errors out with the following information:

error[E0277]: the trait bound `S: MegaAuto` is not satisfied
  --> src/main.rs:18:20
   |
18 |     take_mega_auto(&a);
   |                    ^^ the trait `MegaAuto` is not implemented for `S`
   |
   = note: required for the cast from `&S` to `&dyn MegaAuto`

error[E0277]: the trait bound `S: MegaAuto` is not satisfied in `S_Wrap`
  --> src/main.rs:19:20
   |
19 |     take_mega_auto(&b);
   |                    ^^ within `S_Wrap`, the trait `MegaAuto` is not implemented for `S`
   |
note: required because it appears within the type `S_Wrap`
  --> src/main.rs:10:8
   |
10 | struct S_Wrap(S);
   |        ^^^^^^
   = note: required for the cast from `&S_Wrap` to `&dyn MegaAuto`

This will be a lot more involved, and will require important changes to our type system.

The rest of the month was focused on for-loops and built-in derive macros, which first required a major refactor of our AST and HIR. The problem is as follows: for-loops desugar using the following pattern:

for <pattern> in <iterator> {
  <body>
}

// becomes

{
    let result = match ::std::iter::IntoIterator::into_iter(<iterator>) {
        mut iter => {
            loop {
                let mut __next;
                match ::std::iter::Iterator::next(&mut iter) {
                    ::std::option::Option::Some(val) => __next = val,
                    ::std::option::Option::None => break
                };
                let <pattern> = __next;
                <body>;
            }
        }
    };
    result
}

The paths used in this desugaring are a bit special, as they all start with a leading ::. This is used to indicate that the first path segment should refer to an external crate, and that the path should resolve in one of these crates. This is very useful to prevent ambiguity: If a user were to define their own std module, with an inner option module and an Option enum, simply using the std::option::Option path would resolve to this instead of the expected standard enum.

If for some reason this user-defined enum were to be different, the desugared code would not work, and you would end up with cryptic errors. But since the path is required to resolve in the extern crate std, there are no issues. However, gccrs cannot yet compile the standard library, or distribute it and link it to each program being compiled. Meaning that we would never be able to resolve those paths, at least until we get to compile the standard library. But the standard library contains for-loops, so we’re in a real pickle.

Thankfully, those specific paths used for desugars or macro expansions often refer to specific items that the compiler knows about: lang items. By instead using “lang item paths”, we can refer to these specific items and enum variants to properly desugar our for-loops. But these paths are extremely different from regular, segmented paths, and required a big refactor of both our AST and HIR. Which then allowed us to almost complete the desugaring of for-loops, and improve our handling of built-in macros - another kind of compiler expansion that makes use of lang items you probably already know about, such as Copy or Clone.

We still have a few built-in derives to properly implement in order to support all of them, and close out the Macro expansion milestone of the project. These built-in derives are used all throughout std, and throughout most Rust code, meaning they are essential for compiling the Rust standard library.

If you are interested in helping with these efforts, feel free to pick up any of the issues mentioned in our Call for Contribution or to join the project! We are always available on GitHub or on our Zulip and always happy to see new faces.

Community call

We will have our next monthly community call on the 13th of January at 10am 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

• gccrs: fix ICE during HIR dump PR3346
• ast: Add EnumItem::Kind PR3342
• nr2.0: Resolve type aliases inside trait definitions PR3330
• Resolve and lower parenthesized types PR3328
• parser: Add testcases for multiline strings PR3325
• Add resolution for additional trait bounds PR3324
• nr2.0: Handle `Self` properly in trait definitions PR3323
• ast-builder: Add more methods PR3322
• allow ptr to int and int to ptr type casting PR3321
• ast: Add new Kind enums for more precise downcasting PR3320
• Handle new lang items: `Option::None`, `Option::Some`, `IntoIterator::into<sub>iter</sub>`, `Iterator::next` PR3318
• typecheck-path: Fix typo (reciever -> receiver) PR3317
• gccrs: disable macos github workflow PR3312
• Fix name resolution for enums with generics PR3307
• refactor(typecheck): StackedContexts for blocks PR3305
• gccrs: implement the TuplePattern and use it for function patterns PR3303
• gccrs: fix bad not expression in rust PR3301
• gccrs: Made changes to AST::TraitImpl constructor for TypePath PR3298
• ci: Update expected warnings list for 32 bits build. PR3295
• build: update bootstrap req to C++14 PR3294
• Use lang items as paths PR3290
• Collect lang items in the AST PR3289
• type-check: Remove unused capture in nr2.0 PR3288
• Remove `Rust::make<sub>unique</sub>` PR3278
• Fix `ForeverStack::find<sub>startingpoint</sub>` output parameter PR3247

Contributors this month

• Sri Ganesh Thota (new contributor!)
• Prajwal S N
• Liam Naddell
• Nobel Singh
• Sam James
• Owen Avery
• Marc Poulhiès
• Thomas Schwinge
• Philip Herron
• Pierre-Emmanuel Patry
• Arthur Cohen

Overall Task Status

Bugs

Test Cases

Milestones Progress

Planned Activities

• Implement remaining built-in derive macros
• Implement Send and Sync auto traits
• Finish for-loops code expansion
• Improve our process for updating our github repository with upstream GCC

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 present in this table is no longer present.

Detailed changelog