Rust Search
gccrs is an alternative implementation of a Rust compiler currently being developed. It aims to become a fully fledged Rust compiler, and hopes to share as much code as possible with the official Rust compiler in order to guarantee correctness and avoid damage on the Rust ecosystem. But how do we plan to integrate Rust components to the GCC codebase, and what sort of components will we reuse? This talk will explore the future of the project, as well as some of the challenges surrounding compiler
Recording not playing? Use the FOSDEM link above.
The goal of gccrs is to add support for the Rust programming language to GCC, the GNU Compiler Collection. By being part of the GCC project, gccrs benefits from powerful optimizations and support for a wide range of architectures, as well as a full-fledged plug-in system that further extends Rust’s static safety promises.
Arthur Cohen & Pierre-Emmanuel Patry -- Gccrs, an alternative compiler for Rust, has had the goal of compiling the extremely complex std crate for a few years now. Reaching that milestone will prove that the compiler can handle real Rust code, and allows us to tell you about all the “interesting” compiler tricks we’ve had to deal with.
gccrs is an alternative compiler implementation of the Rust Programming Language, which aims at adding support for the language to the GNU Compiler Collection, GCC. For now, the project targets Rust version 1.49, and plans to catch up once that milestone is reached. But what does “targeting a Rust version” mean? Our goal is for gccrs to eventually become an authentic Rust compiler, which passes the rustc testsuite and contains the same behavior, same bugs, and same language guarantees. But passing a testsuite is only half of the story, and the compiler needs to be useful for Rust users. This means compiling user crates and projects, which most often depend on one of the most complex pieces of Rust code available: the Rust standard library. The standard library provides functions, types and traits that Rust programmers interface with on a daily basis. Think Option, Result, println!(), assert!(), unwrap(), clone()… It is made of multiple crates, of which the most crucial are core and alloc: core contains code usable even in the most restricted embedded contexts, while alloc offers types and abstractions relying on dynamic memory: Vec, Box, String… Some of these abstractions are implemented within the compiler (complex macros such as asm!(), some architecture-specific functions…), but most are written directly in Rust. They are often made of very complex code, utilizing Rust’s powerful type system and macro expansion to avoid boilerplate and ensure soundness - but this weighs heavily on the compiler, which needs to understand and implement these constructs properly to handle this code! This talk will dive into some of the work that was necessary for gccrs to understand and compile Rust’s 1.49 standard library: All of the interesting features, horrible hacks and lawless restrictions we have had to put in the compiler: All of the hurdles, horrors and hoops we’ve had to jump through, and all of the ugly code we’ve had to write! We will focus this talk on the Rust side of things, and take a look at what is necessary for supporting some of the more complex parts of the standard library. We will dive into the rustc 1.49 implementation of the compiler, and compare it to gccrs, highlighting our shortcomings and the evolution of both compilers. You will learn a lot about the language, and discover just how complex the implementation of simple Rust types really is. 🦀 *About Arthur Cohen* 🦀 My name is Arthur Cohen (https://twitter.com/CohenArthurDev), and I am a compiler engineer at Embecosm. I spend my time contributing to gccrs, an alternative compiler for the Rust programming language, and also like to contribute to the official compiler when I can. My other main project is jinko, a statically-typed scripted language with a strong functional background and a powerful type system.
Started in 2014, the gccrs project is working toward creating an alternative compiler implementation for the Rust programming language. At the moment, the project targets the 1.49 version of the language and hopes to catch up once that milestone is reached. In that talk, we will explore some of the components inside gccrs, as well as dive into some of the hurdles encountered during the project's lifetime. Finally, we will explore ways to cross-pollinate with the Rust community, in order to help and benefit both projects. Specifically, we will dive into some ways we plan to share components with rustc, and how to achieve that: namely, we will look at how we plan on integrating the Polonius project to perform borrow-checking inside gccrs, what our efforts with running the rustc 1.49 testsuite are, and what we need to achieve to start being useful to the Rust- for-Linux project.
