November 2024 Monthly report

Overview

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

Project update

GCC development entered stage 3 this month, meaning that gccrs is no longer allowed to submit patches that affect the entire GCC framework until the project re-enters stage 1, after the release of GCC 15.1. This is not an issue for us, as we took special care to send the affected patches upstream back in June of this year, giving them plenty of time to get reviewed and merged before stage 3. In other GCC news, the baseline for building the compiler got bumped from GCC 4.8 to GCC 5.4 - this means that the oldest compiler that we are expected to target is newer and adds support for C++14. Thanks to Sam James and Marc Poulhiès, we have updated our CI to reflect this change. Thank you both!

Most of the pull-requests this month were focused on name resolution, with even more improvements made by Owen Avery. Owen has been a contributor to the project for two years, and has been extremely helpful recently with our name resolution rewrite (NR2.0), by working on integrating it to all areas of the compiler. We will thus be welcoming Owen to the core gccrs team of contributors.

An interesting technical change this month concerns the type-checking of match expressions. In one certain case, match expressions can resolve to the never type. This is interesting for empty ~enum~s, which can be used to represent invalid or impossible states. A well known type from the standard library is Infallible, whose definition is as follows:

enum Infallible {}

Since this enum does not contain any variants, matching on it looks a bit strange:

fn handle_infallible(x: Infallible) {
    let y = match x {};
}

In that case, what should the type of y be? Since we cannot extract any information from x, it doesn’t really make sense to give y a regular type. Furthermore, since we cannot instantiate a value of type Infallible in the first place, it does not make sense to do pattern-matching on it to extract information! But by making this pattern matching resolve to the never type, we can implement traits on Infallible in order to use it just like a regular error type - since never can always coerce to any target type, as it cannot exist in the first place. This makes empty pattern matching required for handling the Infallible type and its trait implementations, which is required for handling code that can never fail. The documentation of the enum gives an interesting example, in which the TryFrom<T> trait can be implemented for U when U already implements From<T>. Because we know the conversion can never fail, there is no need to expose a proper error type, as those errors will never show up.

The fix for this is quite simple - if the match we are type-checking is empty, then we can just resolve its type to never. If the match is not supposed to be empty (for example, if we are matching on an enum with one or more variants), then it’s up to the exhaustiveness checker to report an issue - not the type-checker!

If you are curious, you can see how this special case is handled in gccrs and in rustc.

In other technical news, Antoni Boucher, lead developer of the rustc_codegen_gcc project, contributed code to gccrs this month in order to improve target feature detection for both of our projects. This code concerns platform-specific information that the compilers needs to know about in order to produce correct assembly. By reusing the same code in both projects, we ensure that Rust code compiled using one of the GCC-based compilers will behave the same way on the users’ machines. This change also makes it easier to adapt our target configuration values for Rust if the need arises. Thank you Antoni!

Finally, a blogpost written in collaboration with the Rust project was also published on the official Rust blog: https://blog.rust-lang.org/2024/11/07/gccrs-an-alternative-compiler-for-rust.html. This blogpost outlines some of the decisions we’ve made for gccrs to make sure that the project does not threaten the Rust ecosystem and does not risk splitting it in two. The main discussion thread about it can be found here on Reddit, where it was really well-received.

Community call

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

There are no calls for contribution this month, as we do not have a lot of good first issues available. Still, feel free to take a look at them here and get in touch with us for some mentoring or help!

Completed Activities

• hir: Remove duplicate function in TraitItemFunc PR3276
• Cleanup lang items mappings PR3273
• gccrs: ensure packed and aligned is applied properly PR3272
• gccrs: allow casts from numeric types to floats PR3270
• gccrs: improve handling of Self Type paths PR3269
• ci: bump actions/checkout version and fix gcc 5 testing PR3268
• gccrs: fix crash in hir dump with missing guards PR3267
• Prepend crate name to functions with nr2 PR3265
• ci: remove bors mention PR3263
• CI: upgrade GCC baseline from 4.8 -> 5.4 (5.5) PR3262
• Clean up some system includes PR3259
• Prevent execution of some nr1.0 functions with nr2.0 PR3257
• gccrs: empty match expressions should resolve to ! PR3256
• Add a new CI step to detect raw issue references in commit messages PR3255
• Handle type path segments during late resolution 2.0 PR3254
• Use nr2.0 in typechecker PR3253
• Use nr2.0 in `PrivacyReporter` PR3252
• gccrs: Fix bad handling for recursive type query PR3250
• Push ribs by kind rather than by value PR3249
• Improve handling of static items in toplevel 2.0 PR3248
• Cleanup clang warnings PR3244
• gccrs: add test case to show issue is fixed PR3243
• Fix bad type checking on fn trait calls PR3240
• Use name resolver 2.0 in `VisibilityResolver` PR3239
• Improve handling of implicit `Self` parameter in AST PR3238
• gccrs: fix bad type inference on local patterns PR3237
• Improve handling of struct expressions in nr2.0 PR3225
• Use name resolver 2.0 for module descendance checks PR3224
• Reorganize the CPU feature detection PR3195
• Add build dependencies for Fedora PR3154
• Reduce the amount of raw pointer the HIR API PR2878

Contributors this month

• Antoni Boucher (new contributor!)
• Sam James (new contributor!)
• Jarkko Sakkinen (new contributor!)
• Philip Herron
• Pierre-Emmanuel Patry
• Arthur Cohen
• Owen Avery
• Marc Poulhiès
• Thomas Schwinge

Overall Task Status

Test Cases

Bugs

Milestones Progress

Planned Activities

• Finish usage of lang items for codegen
• 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