GCC Rust Weekly Status Report 31

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

Milestone Progress

Last week’s report discussed how I had been blocked on my work into closures as we are missing support for Rust’s lang-item system, which we knew we needed for the goal test case. This week, I have been thinking about the steps we need to take to work with lang items and fixing known bugs associated with this milestone to continue making progress. From reading through the rustc test suite, this test case has rattled out quite a few issues, though there is one final issue to fix before compiling this test case properly to do with the specified constraints. However, overall I am making steady progress, and I am on track to win back about half the lost time from the previous milestone.

Hacktoberfest 2021

https://hacktoberfest.digitalocean.com/ we have marked out repository as part of the hacktoberfest community event feel free to join in, there are plenty of good first PR’s to tackle: https://github.com/Rust-GCC/gccrs/issues?q=is%3Aissue+is%3Aopen+label%3Agood-first-pr

Monthly Community Call

We will be having our 8th community call as the first Friday of the month:

Completed Activities

  • Fix ICE in trait resolution PR752 PR758 PR759 PR760
  • Add new unsafety enum instead of bool fields PR754
  • Use const to enforce pointer ownership within the type checker PR756
  • Support generic associated TypePaths via the type-bounds PR757
  • Fix bootstrap build PR761
  • Add missing coercion code generation for arguments in MethodCallExpr PR762
  • Fix naming of generic function symbols in gimple PR763
  • Update copyright years PR764

Contributors this week

Overall Task Status

CategoryLast WeekThis WeekDelta
In Progress1512-3
GitHub Issues

Test Cases

CategoryLast WeekThis WeekDelta
make check-rust


CategoryLast WeekThis WeekDelta
In Progress83-5
GitHub Bugs

Milestones Progress

MilestoneLast WeekThis WeekDeltaStart DateCompletion DateTarget
Data Structures 1 – Core100%100%30th Nov 202027th Jan 202129th Jan 2021
Control Flow 1 – Core100%100%28th Jan 202110th Feb 202126th Feb 2021
Data Structures 2 – Generics100%100%11th Feb 202114th May 202128th May 2021
Data Structures 3 – Traits100%100%20th May 202117th Sept 202127th Aug 2021
Control Flow 2 – Pattern Matching20%40%+20%20th Sept 202129th Nov 2021
Macros and cfg expansion0%0%1st Dec 202128th Mar 2022
Imports and Visibility0%0%29th Mar 202227th May 2022
Const Generics0%0%30th May 202225th Jul 2022
Intrinsics0%0%6th Sept 202130th Sept 2022
GitHub Milestones


RiskImpact (1-3)Likelihood (0-10)Risk (I * L)Mitigation
Rust Language Changes3721Keep up to date with the Rust language on a regular basis
Going over target dates3515Maintain status reports and issue tracking to stakeholders

Planned Activities

Detailed changelog

Support generic associated TypePaths

Traits can have associated types like we have seen before in previous reports, but for generic functions for example we can specify bounds on the type ‘T’ in this case which means that TypePath’s need to support looking up associated types via ‘probing’ the bounds of the type to find that the placeholder type ‘A’ exists. Which will get setup with the appropriate projection at monomorphization.

trait Foo {
  type A;

fn test<T:Foo>(a:T) -> T::A { .. }

Fix ICE in autoderef for generic MethodCallExpr

When we have generic functions such as:

pub trait Foo {
    type A;

    fn bar(&self) -> Self::A;

fn test_bar<T: Foo>(x: T) -> T::A {

The method call here requires an implict borrow (‘&’) to be able to call bar correctly. The compiler was unable to distinguish the difference between the type parameter T and the expected &self so it was unable to generate the implicit adjustment of adding the borrow but this is now fixed.

Fix bug in typechecking of associated types

pub trait Foo {
    type A;

    fn bar(&self) -> Self::A;

struct S(i32);
impl Foo for S {
    type A = i32;

    fn bar(&self) -> Self::A {

fn test_bar<T: Foo>(x: T) -> T::A {

We had a bug when using associated types within generic functions. The compiler wrongly associated impl’s of traits together for generic types. This means that when you used a Path to call a method this means it would automatically project all of the associated types with the impl we found, which resulted in errors like this which don’t make any sense to the programmer.

test.rs:15:5: error: expected [i32] got [<Projection=::i32>]
   15 |     type A = i32;
      |     ^        ~

The bug here is that when we probe the bounds of a type we don’t have any associated impl’s to project the placeholder associated types.

Ensure arguments to MethodCallExpr emit code for coercion-sites

When we have coercion sites such as passing arguments to a function, these are chances for missing conversions.

struct S;
impl S {
    fn dynamic_dispatch(self, t: &dyn Bar) {

fn main() {
    let a;
    a = &Foo(123);

    let b;
    b = S;


In this example ‘a’ is of type &Foo which is fine as an argument to static_dispatch but for dynamic dispatch this needs to be converted into a vtable object. This is the same for the case when we have:

fn main() {
    let a;
    a = &Foo(123);

    let b: &dyn Bar = a;

The bug in the compiler is that this coercion_site was not being called for argument passing to implicitly convert the orginal argument.

Leave a Reply

Your email address will not be published.