This page contains information about the 9 projects that were
accepted
into Google Summer of Code 2024
under the Rust Project organization.
- Allow customizing lint levels and reporting in
cargo-semver-checks - Fast(er) register allocator for Cranelift
- Improve Rust benchmark suite
- Move cargo shell completions to Rust
- Rewriting Esoteric, Error-Prone Makefile Tests Using Robust Rust Features
- Rewriting the Rewrite trait
- Rust to .NET compiler - add support for compiling & running cargo tests
- Sandboxed and Deterministic Proc Macro using Wasm
- Tokio async support in Miri
This project was implemented by Max Carr.
Description
cargo-semver-checks is a linter for semantic versioning. It ensures
that Rust crates adhere to semantic versioning by looking for breaking changes in APIs.
Currently, semver lints have a hardcoded level (e.g. breaking changes are "major") and are always reported at a "deny" level: if the release being scanned is a minor version bump, any lints at "major" level are reported as errors.
This can be insufficient for some projects, which may desire to:
- configure some lints to have a different level — e.g. turn a semver "major" lint into a "minor" lint, or vice versa
- turn some lints into warnings instead of hard errorrs — reporting level "warn" instead of the default "deny"
- disable some lints altogether by setting their reporting to "allow"
- (stretch goal) allow customizing lint levels and reporting on a per-module basis
Having such functionality would allow cargo-semver-checks to ship additional lints that target changes whose semver
implications are defined by project maintainers on a per-project basis. An example of such a change is bumping the
minimum supported Rust version (MSRV) of a project — some projects consider it a semver-major change, whereas for
others it is minor or patch.
This functionality would also allow us to write lints similar to clippy's "suspicious" lint group, flagging code that is suspect (and deserving of closer scrutiny) but possibly still correct. Such lints should be opt-in / "warn" tier to avoid annoying users, which is something this project would enable us to do.
Expected result
cargo-semver-checks lints will be configurable via the package.metadata table in Cargo.toml
using a clear, simple and expressive way. The design will be suitable for both single-crate projects and workspaces.
Desirable skills
Intermediate knowledge of Rust.
Project size
Large.
Difficulty
Medium.
Mentor
Related links
This project was implemented by Demilade Sonuga.
Description
The Rust compiler uses various codegen backends to generate executable code (LLVM, GCC, Cranelift). The Cranelift backend should provide very quick compile times, however its performance is currently relatively bottlenecked by its register allocator.
The goal of this project is to implement a new register allocator for Cranelift, that would be tuned for very quick compilation times (rather than optimal runtime performance of the compiled program). A first attempt could simply create an allocator that spills all registers to stack, and a possible follow-up could be a linear scan allocator. It would be useful to compare the compilation vs runtime performance trade-offs of various register allocation approaches.
Expected result
It will be possible to use a new register allocator in Cranelift that will work at least for simple programs and that will improve Rust compilation times.
Desirable skills
Intermediate knowledge of Rust. Basic knowledge of assembly. Familiarity with compiler technologies is a bonus.
Project size
Medium.
Difficulty
Medium.
Mentors
This project was implemented by s7tya.
Description
Rust has an extensive benchmark suite that measures the performance of the Rust compiler and Rust programs and visualizes the results in an interactive web application. It received a lot of new features in the past few years, however some of them are not as polished as they could be.
The goal of this project is to improve both the frontend website and its various dashboards, and also profiling and analysis tools used to examine benchmarks in the suite. As an example, improvements could be made in the following areas:
- Runtime benchmarks. The suite recently got support for runtime benchmarks that measure the performance of Rust programs
compiled by a specific version of
rustc(the Rust compiler). There is a lot of features that could be added to get runtime benchmarks to the same support level as compile-time benchmarks, like adding and visualizing benchmark variance analysis for them or adding runtime benchmark results to various dashboards in the frontend. - Analysis of multithreaded performance. The Rust compiler has recently gained support for using multiple threads for its frontend, but there is no configuration in the suite to parametrize how many threads will be used, nor any analysis of how well are threads utilized. It would be nice to add analysis and visualisation for this.
- Some pages of the website still use HTML templates. It would be great to port these to the Vue-based frontend.
Expected result
New analyses will be available in the Rust benchmark suite, and/or the suite website will contain more useful data and visualizations.
Desirable skills
Basic knowledge of Rust, intermediate knowledge of frontend web technologies (TypeScript, HTML, CSS, Vue).
Project size
Medium.
Difficulty
Medium.
Mentor
This project was implemented by Shanmu.
Description
Cargo maintains Bash and Zsh completions, but they are duplicated and limited in features. We want to implement completions in Cargo itself, so we can have a single implementation with per-shell skins (rust-lang/cargo#6645). Most of the implementation will be in clap (clap-rs/clap#3166), allowing many tools to benefit from this improvement.
Expected result
Cargo shell completion will be extended and implemented in Rust. This will allow access to easier to add new commands / arguments to commands, richer results, and easier testing.
Desirable skills
Intermediate knowledge of Rust. Shell familiarity is a bonus.
Project size
Medium.
Difficulty
Medium.
Mentor
This project was implemented by Julien Robert.
Description
The Rust compiler currently uses a so-called run-make test suite for complex test scenarios that involve other tools (e.g. bash utilities, linkers, etc.) in addition to the compiler itself. As the name suggests, these tests are based on make, and they invoke various tools to test complex situations.
However, this approach has a number of drawbacks:
- Because the tests are based on commandline tools like
nmandgrep, test authors and reviewers have to know the syntax of these tools, which can be quite arcane and is often interleaved with Makefile's own syntax. - Tests are hard to read because they are based on commandline tool exit codes.
- It is quite hard to write these tests in a cross-platform way, since each implementation often behaves slightly differently. This leads to various issues and workarounds, especially on non-Unix platforms.
- In many cases, when a test fails, it is quite hard to find where exactly it failed.
- It is quite easy to write a test that looks fine, but actually does not test anything (e.g. testing that certain text is not present in the output passes because a program silently fails to produce any output).
The goal of this project is to replace these Makefile tests with a new test harness, where the tests would be written using regular Rust code. To support these tests, a support library should be implemented, which will be used by the tests to perform common actions, such as invoking the compiler, grepping files, checking symbols, finding tools, and providing readable error messages when a test fails. The support library can rely on commandline tools under the hood, but it should provide a nice Rust API that behaves the same on all platforms. The tests can be ported to the new framework one at a time, and the old Makefile framework can be removed once all tests are ported.
There is currently already an open PR that has initiated some of what is described here, however there is still a lot of follow-up work left to be done.
Expected result
run-make tests are replaced with an ergonomic and well-documented Rust-based test infrastructure. A fraction of the old
run-make tests are ported to the new Rust-based test infrastructure.
Desirable skills
Intermediate knowledge of Rust.
Familiarity with standard bash utilities and their behavior preferred (e.g. grep, nm and others).
Project size
Large.
Difficulty
Medium.
Mentors
Related links
This project was implemented by SeoYoung Lee.
Description
The internal formatting mechanisms in rustfmt has issues tracking the context when issues occur when applying formatting. This can lead to silent failures and limit the ability for rustfmt to retry formatting. A potential solution would be to refactor the Rewrite trait, currently used to format various AST structures, which could improve how we handle situations where it failed to format.
More details in the discussions linked below.
Expected result
Improved user experience with less silent failures (provide context as to how and why formatting failed) and allowing rustfmt to retry formatting under more contexts.
Desirable skills
Intermediate knowledge of Rust. Understanding of AST (Abstract Syntax Tree) structures are welcomed, but not required.
Project size
Medium.
Difficulty
Medium.
Mentor
Related Links
This project was implemented by Fractal Fir.
Description
This project aims to extend the ability of rustc_codegen_clr, the Rust to .NET compiler backend, to run cargo tests.
While the project is already quite feature-rich, it still can't compile Rust tests properly. This project will focus on adding all the features necessary for such tests to run, with the end goal of running them within the .NET runtime. Adding those features will not only enable running tests, it will also improve the project, enabling it to compile far more Rust programs.
At the end of GSoC, this project will deliver the following features:
- Support for parsing command line arguments in Rust programs running within the .NET runtime.
- Implementation of atomic intrinsics needed for
stdargument parsing to function properly. They should be implemented using cross-platform .NET APIs, but using architecture-specific functions may be needed to properly handle certain atomics. - Support for dynamic trait objects - creating them, dropping them, calling their member functions.
- Support for catching panics, implemented using the .NET exception-handling primitives.
- Support for multithreading: launching threads, and getting information about them.
- Extended .NET interop, automatic creation of safe GC handles for managed objects. This feature is necessary for safely handling .NET threads, but will be exposed in the
mycorrhizainterop layer, provided by the codegen. - Fixes to string formatting. This feature is necessary for reporting test results. At the end of this proposal, simple formatting, such as
format!("my string is:{string}")should run within the .NET runtime. The end goal of this proposal is running a simple cargo test within the .NET runtime. This test will consist of two cases: one failing, and one passing. All the deliverables mentioned above are strictly needed for achieving that goal.
Expected result
The .NET Rust codegen backend will be able to run Rust tests and potentially even the Rust compiler test suite.
Desirable skills
Intermediate knowledge of Rust and .NET.
Project size
Large.
Difficulty
Medium.
Mentor
This project was implemented by Apurva Mishra.
Description
Add experimental support to rustc for building and running procedural macros as WebAssembly. Procedural Macro crates can opt in for being compiled to WebAssembly. This wasm-proc-macro will be a wasm blob sandboxed using WASM. It will interact with the compiler only through a stream of token and no ability to interact with the outside world.
Expected result
Proof of concept of proc macros that are compiled to WebAssembly, integrated within rustc.
Desirable skills
Intermediate knowledge of Rust.
Project size
Medium.
Difficulty
Large.
Mentor
This project was implemented by Tiffany Pek Yuan.
Description
Miri is a testing tool to check undefined behaviour in unsafe Rust. Currently, a significant portion of Tokio async program still cannot be effectively tested with Miri due to unhandled system calls. This project aims to rectify this limitation by offering support for Tokio async in Miri through a complete implementation of epoll shim. By doing so, it will open up a whole new part of the async ecosystem to be tested with Miri, ensuring greater reliability and stability in Rust ecosystem.
Expected result
Ability to support programs with epoll and similar syscalls in Miri.
Desirable skills
Intermediate knowledge of Rust.
Project size
Large.
Difficulty
Medium.
Mentor