GCC Rust Weekly Status Report 56

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

Milestone Progress

Another week into July, we closed out the imports and visibility milestone. This allows us to focus on bug fixing and const generics, and I have also adjusted our expected target dates for the milestones as we went over previously. Moving forward, we hope to focus on not losing too much time as we know that September is a busy month with three back-to-back conferences for us, which will impact development. In other news, we have started extracting patches from gccrs that affect GCC for review on gcc-patches.

Completed Activities

• cpp const-exprt porting PR1369
• Support more foreign ABI’s PR1375 PR1379
• Bug fix bad arithmetic type checking on generics PR1384
• Support generics in AST dump PR1382
• Support arithmetic expressions in AST dump PR1381
• Bug fix support aggregate types in transmute PR1380
• Add crate helpers in mappings class PR1388
• External items with Rust ABI need name mangling PR1387
• Fix undefined behaviour with unique_ptr PR1386
• Add missing include PR1385
• Update build farm badges PR1390
• Extern crate loading PR1362
• Fix ICE on extern block PR1391

Contributors this week

• Faisal Abbas
• liushuyu

Overall Task Status

Category	Last Week	This Week	Delta
TODO	151	152	+1
In Progress	27	27	–
Completed	410	413	+3

Test Cases

Category	Last Week	This Week	Delta
Passing	6442	6468	+26
Failed	–	–	–
XFAIL	31	31	–
XPASS	–	–	–

Bugs

Category	Last Week	This Week	Delta
TODO	68	69	+1
In Progress	11	12	+1
Completed	170	172	+2

Milestone Progress

Milestone	Last Week	This Week	Delta	Start Date	Completion Date	Target
Data Structures 1 – Core	100%	100%	–	30th Nov 2020	27th Jan 2021	29th Jan 2021
Control Flow 1 – Core	100%	100%	–	28th Jan 2021	10th Feb 2021	26th Feb 2021
Data Structures 2 – Generics	100%	100%	–	11th Feb 2021	14th May 2021	28th May 2021
Data Structures 3 – Traits	100%	100%	–	20th May 2021	17th Sept 2021	27th Aug 2021
Control Flow 2 – Pattern Matching	100%	100%	–	20th Sept 2021	9th Dec 2021	29th Nov 2021
Macros and cfg expansion	100	100%	–	1st Dec 2021	31st Mar 2022	28th Mar 2022
Imports and Visibility	98%	100%	+2%	29th Mar 2022	13th Jul 2022	27th May 2022
Const Generics	15%	30%	+15%	30th May 2022	–	29th Aug 2022
Intrinsics	0%	0%	–	6th Sept 2022	–	30th Sept 2022

Risks

Risk	Impact (1-3)	Likelihood (0-10)	Risk (I * L)	Mitigation
Rust Language Changes	2	7	14	Target specific Rustc version for first go
Going over target dates	2	7	14	Maintain status reports and issue tracking to stakeholders

Planned Activities

• Investigate type checking const-generic arguments
• Work on overflow traps
• Bug fixing
• Extract target hooks patches for gcc-review

Detailed changelog

Linking crates

In Rust, the entire crate is the compilation unit; for reference, a compilation unit is often referred to as the translation unit in GCC. This means, unlike other languages, a crate is built up with multiple source files. This is all managed by the mod keywords in your source code, such that mod foo will expand automatically to the relative path of foo.rs and include the source code akin to an include nested within a namespace in C++. This has some exciting benefits, notably no need for header files, but this means more complexity because, when linking code, the caller needs to know the calling conventions and type layout information.

To support linking against crates, many things come together to let it happen, so let us look at this by considering a simple example of calling a function in a library. Let us assume we have a library foo with directory structure:

// libfoo/src/lib.rs
fn bar(a:i32) -> i32 {
  a + 2
}

We can compile this by running:

gccrs -g -O2 -frust-crate=foo -c src/lib.rs -o foo.o

This will generate your expected object file, but you will notice a new output in your current working directory: foo.rox. This is your crate metadata; it contains all this “header” information, such as functions and type layouts. There is code to this by embedding this metadata directly into the object file, which will be preserved into static libraries, and the compiler will support reading from object files and archives but not shared objects, unfortunately. However, by emitting this separate file, it means its output format is agnostic as this method does not seem to be supported for us on macosx.

Back to the example, in order to link against this object and call the function, we must write code to import it:

// test/src/main.rs
extern crate foo;
use foo::bar;

fn main() {
  let a = bar(123);
}

Now to compile and link this.

gccrs -g -O2 -I../libfoo -c src/main.rs -o main.o
gccrs -o test main.o ../libfoo/foo.o

In the compiler, we see the extern crate declaration, which tells the compiler to look for the external crate foo, which in turn triggers the compiler to look for foo.rox, foo.o or libfoo.a in this case, we will find foo.rox. The front-end loads this data, so we know there is a function named bar. Internally the crate of foo just exports:

extern "Rust" {
  fn bar(a:i32) -> i32;
}

This is more complicated for generics and impl blocks, but the idea is the same. The benefit of exporting raw rust code here is that to support public generics, we just get this for free by reusing the same compiler pipeline.

Note you can use the following options to control this metadata output so far:

• -frust-embed-metadata this toggles to embed the metadata into .rust_export section of the target asm output default off
• -frust-metadata-output= specifies the path to directly write the metadata to file

Note 1: that when specifying the location to write this metadata file the compiler will enforce a naming convention of crate_name.rox on the basename of the path as the crate name is critical here. Note 2: this link model is heavily inspired as that from gccgo.