March 2023 Monthly report

Overview

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

Milestone Progress

We have received many GSoC proposals over the past few weeks and are starting to review them in more detail. Remember, proposals are open until the 4th of April, and will be reviewed until the 27th of April. We kept on receiving a high number of contributions this month, with around 50 PRs submitted, reviewed and merged in three weeks. Please note that why this amount is lower than previous months, this report was also written and published a week earlier than past months. Out of 13 proposals submitted to the GSoC portal so far, 9 of them concern gccrs.

We have opened many issues pertaining to the compilation of libcore 1.49 and feel confident that we are getting closer and closer to compiling it. However, due to the GCC staging process, we will not be able to make the changes required to the build system for libcore to be distributed as part of GCC 13, nor will we have a completely working version of libcore at this point. In the last few weeks that remain before GCC 13 releases, we will not be able to implement some of the more complex features remaining, such as inline assembly, format string parsing and handling, or the remaining compiler builtins.

For this reason, we have chosen to go with quite an early cutoff for the GCC 13 release, which means we’ll have more time to focus on documentation and user experience for the GCC 13 release. We will spend some time in the coming weeks upstreaming commits to GCC’s master and figuring out our next steps for the compiler.

Arthur also spent one week this month at Embedded World talking about the project with many interesting people from different backgrounds. Thank you to everyone who stopped by or attended our little Rust compilation challenge. We had pleasant discussions around gccrs with individuals from AdaCore and Ferrous Systems and had a lovely time.

Finally, one of the big changes this month was the renaming of our compiler proper from rust1 to crab1. The compiler proper is different from the compiler driver, gccrs, which users interact with. Because only gccrs hackers will ever interact with the compiler proper, we thought it would be fun to change its name. The project was originally started as a hobby and passion project, and we think that keeping things light is an important aspect of it. Hence, if you do contribute to gccrs, you’ll now use gcc/crab1 instead of gcc/rust1 to see if your changes have taken into effect!

Community call

We had our monthly community call on the 3rd of April. 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.

• Calendar ID: 7060a0923ffebd3cb52b1afef35a28ff7b64f05962c9af84c23b1847f1f5f894@group.calendar.google.com
• Google calendar link
• iCal link

Completed Activities

• gccrs: Fix bad cast as a char PR2078

• gccrs: Add test to show multiple candidates for methods is working PR2071

• gccrs: Add missing known attribute stable PR2069

• gccrs: move missed testcase PR2068

• gccrs: handle bare function types with no specified return type PR2067

• gccrs: fix ICE when closure body is not a block PR2066

• gccrs: fix ICE with bad match arm type PR2065

• Fix bad handling of generic lifetimes PR2063

• gccrs: Fix bad cast error to bool PR2062

• Remove commented out TuplePatternItemsSingle PR2058

• ast: Refactor rust-ast-lower-type.h to source file PR2057

• Add proper support for `pub(crate)` PR2056

• docker: Do not run update-alternatives on invalid path PR2055

• Fix parsing of array expressions. PR2051

• gccrs: Fix ICE on parsing trait object missing dyn keyword PR2046

• gccrs: Fix bad type inference PR2018

• Split Cfg stripping and macro expansion phase PR2016

• ast: Dump each MacroRule properly without the extra semicolon PR2014

• rust-imports: Fix last few mentions of Go. PR2013

• Support use declaration to export the type properly PR2011

• gccrs: Cleanup unused headers PR2010

• Lower AltPattern PR2008

• Add name resolution and ast lowering for SlicePattern PR2007

• Remove unused ResolvePattern visitor PR2006

• Fix bad method resolution and add move_valinit PR1999

• resolve: Fix multiple bindings handling in match PR1997

• Unify HIR::IfLetExprConseqIf{,Let} into HIR::IfLetExprConseqElse PR1995

• Unify HIR::IfExprConseqIf{,Let} into HIR::IfExprConseqElse PR1994

• resolve: Add name resolution for AltPattern PR1993

• ci: Do not run `check-gccrs-prefix` on PRs to master PR1992

• Lower public macros to mappings PR1991

• Cleanup PR1990

• hir: Improve pattern bindings handling in closure parameters PR1989

• gccrs: Rename compiler proper to crab1 PR1988

• resolve: Handle multiple bindings to the same identifier PR1983

• hir: Fix `ReferencePattern` typechecking PR1980

• ci: check Signed-off-by lines (and others) are at the end PR1979

• Unify AST and HIR dump indentation PR1978

• Cleanup type system and fix bad type monomorphization PR1977

• Impl `Rust::HIR::Dump::visit` PR1976

• hir: Provide basic handling for `ReferencePattern` PR1974

• Allow all keywords (except `priv`) to follow `:vis` in macro rules PR1965

• enr: Fetch module items during early name resolution PR1957

• Fix `FeatureGate::gate` will crash on 32-bit x86. PR1956

• hir: Add ExportedMacro node and handling. PR1947

• librust: Add libproc_macro and build system PR1913

• `libproc<sub>macro</sub>` rust interface PR1856

• ci: Separate dependencies and running testsuites steps PR47

• ci: Set workspace as one of git’s safe.directory PR46

• ci: Allow running workflow manually PR45

• ci: Mark workspace as safe directory for git operations PR44

• ci: Do not use GitHub’s checkout anymore PR43

• Remove Rust submodule PR42

• Update testing project PR41

Contributors this month

• tage64 (new contributor!)
• emanuel-em (new contributor!)
• Pierre-Emmanuel Patry
• mxlol233
• Arsen Owens
• Mahmoud Adel
• Marc Poulhiès
• Jakub Dupak
• Vincent Fan

Overall Task Status

Test Cases

Bugs

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.

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

• Finish patch upstreaming
• Finish macro name resolution
• libproc
• Iterators and Bugs

Detailed changelog

Bare trait objects

During testing libcore code we found that we didn’t support bare trait objects where it does not specify the ‘dyn’ keyword: https://doc.rust-lang.org/nightly/edition-guide/rust-2021/warnings-promoted-to-error.html#bare_trait_objects

This is depreciated code but we aiming to compile older versions of libcore first so we need to be able to handle this before this became a hard error.

trait Foo {
    fn bar(&mut self, other: &mut Foo);
}

struct Baz;
impl Foo for Baz {
    fn bar(&mut self, other: &mut Foo) {}
}

Reference patterns

One of our new contributors Mahmoud Adel has been working on adding support for patterns within gccrs. Reference patterns was added recently which allows the users to automatically destructure the reference parameters here to their element types without requiring dereference syntax.

fn foo (&a: &i32, b: i32) -> i32 {
  a + b
}

Use declarations as the Rustc prelude

When working with Result and Option gccrs did not support the prelude use declarations which meant you had to specify Option::Some or Result::Ok rather than the usual Ok and Some. In order to support this Rust uses a special decalration to add these enum variant names directly to the namespace so for exmaple:

pub use result::Result::{self, Err, Ok};

extern "C" {
    fn printf(s: *const i8, ...);
}

mod result {
    pub enum Result<T, E> {
        #[lang = "Ok"]
        Ok(T),

        #[lang = "Err"]
        Err(E),
    }
}

pub fn test(a: i32) -> Result<i32, bool> {
    if a > 5 {
        Ok(123)
    } else {
        Err(false)
    }
}

Due to the use declaration it is now ok to directly use Err and Ok without specifying Result::<variant> directly.

Renaming our compiler proper from rust1 to crab1

This is an important change going forward to remember to have fun. For those who are not aware when you invoke gcc to compile C code fro example you should try doing so but pass the ‘-v’ flag and you will see that it ends up invoking a program called ‘cc1’. For gccrs we used to invoke one called rust1 we have now renamed this ‘crab1’.

See our zulip for fun discussions on this and associated PR https://github.com/Rust-GCC/gccrs/pull/1988

Add length checks for tuple patterns

When assigning tuples and patterns in general we did not have any sized checks so it used to be possible to assign a pattern of differing sizes which would lead to UB and or and ICE. Thanks to one of our new contributors Nikos Alexandris we now have proper checks such as:

fn foo() -> i32 { // { dg-error "expected .i32. got .bool." }
    let (a, _) = (true, 2, 3); // { dg-error "expected a tuple with 3 elements, found one with 2 elements" }
    a
}

see: https://godbolt.org/z/3njj6K14j

Uninit intrinsic

Although we add intrinsics fairly regularly this one is interesting from a compiler perspective, sometimes you just need uninitilized memory which is used in the mem::ptr modules in libcore which gets called from the iterator code to swap data around for the next element. We got some advice from bjorn3 here on our zulip which suggests the best way to implement an uninit intrinsic is to memset with 0x01 as it seems to be the least dangerous in an unsafe context.

• https://github.com/Rust-GCC/gccrs/pull/1948
• https://github.com/Rust-GCC/gccrs/issues/1899
• https://gcc-rust.zulipchat.com/#narrow/stream/266897-general/topic/Rust.20uninit.20intrinsic/near/328521116

As rust is designed to limit unitilized memory it would be great in the future to look at this in more detail in the future for now we are copying Rustc.