The Rust project has decided to join Google Summer of Code 2024 (GSoC) for the first time in 2024! This page contains project ideas that could benefit Rust maintainers and the whole Rust community.
We invite contributors that would like to participate in GSoC to examine the project list and use it as an inspiration for your project proposals. You can also propose a project that is not included in this list, for example an improvement of some Rust crate. However, please note that ultimately, each project needs at least one mentor. We have tried to make sure that all the ideas listed here would have a mentor available, but if you propose a different project, you might have to find someone who would be willing to mentor you.
You can find some tips for applying for a Rust GSoC project here.
If you would like to discuss projects ideas or anything related to the Rust Project's involvement in GSoC 2024, you can
do so on the #gsoc Zulip stream.
- Rust Compiler
- Infrastructure
- Cargo
- Crate ecosystem
The list of ideas is divided into several categories.
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 or large.
Difficulty
Medium.
Mentors
Zulip streams
Description
rustc currently has three in-tree codegen backends: LLVM (the default), Cranelift, and GCC.
These live at https://github.com/rust-lang/rust/tree/master/compiler, as rustc_codegen_* crates.
The goal of this project is to add a new experimental rustc_codegen_c backend that could turn Rust's internal
representations into C code (i.e. transpile) and optionally invoke a C compiler to build it. This will allow Rust
to use benefits of existing C compilers (better platform support, optimizations) in situations where the existing backends
cannot be used.
Expected result
The minimum viable product is to turn rustc data structures that represent a Rust program into C code, and write the
output to the location specified by --out-dir. This involves figuring out how to produce buildable C code from the
inputs provided by rustc_codegen_ssa::traits::CodegenBackend.
A second step is to have rustc invoke a C compiler on these produced files. This should be designed in a pluggable way,
such that any C compiler can be dropped in.
Desirable skills
Knowledge of Rust and C, basic familiarity with compiler functionality.
Project size
Large.
Difficulty
Hard.
Mentor
Zulip streams
Description
rustc currently has incomplete support for using annotate-snippets
to emit errors, but it doesn't support all the features that rustc's built-in diagnostic rendering does. The goal
of this project is to execute the rustc test suite using annotate-snippets, identify missing features or bugs,
fix those, and repeat until at feature-parity.
Expected result
More of the rustc test suite passes with annotate-snippets.
Desirable skills
Knowledge of Rust.
Project size
Medium.
Difficulty
Medium to hard.
Mentor
Zulip streams
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. Currently, the benchmarks are gathered on a single physical machine, however we are hitting the limits of how many benchmark runs we can perform per day on a single machine, which in turn limits the benchmark configurations that we can execute after each commit.
The goal of this project is to add support for splitting benchmark execution across multiple machines. This will require a refactoring of the existing suite and potentially also database schema modifications and implementation of new features.
Expected result
It will be possible to parallelize the execution of the benchmark suite across multiple machines.
Desirable skills
Intermediate knowledge of Rust and database technologies (SQL).
Project size
Medium or large.
Difficulty
Medium.
Mentor
Zulip stream
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
Zulip streams
Description
The Rust compiler it bootstrapped using a complex set of scripts and programs generally called just bootstrap.
This tooling is constantly changing, and it has accrued a lot of technical debt. It could be improved in many areas, for example:
- Design a new testing infrastructure and write more tests.
- Write documentation.
- Remove unnecessary hacks.
Expected result
The bootstrap tooling will have less technical debt, more tests, and better documentation.
Desirable skills
Intermediate knowledge of Rust. Knowledge of the Rust compiler bootstrap process is welcome, but not required.
Project size
Medium or large.
Difficulty
Medium.
Mentor
Zulip streams
Description
Rust infrastructure uses many custom tools designed for automating pull request merging, handling discussions on Zulip, managing GitHub permissions etc. It would be a great help to Rust maintainers if these tools were improved. Here are a few possible tasks that could be implemented:
- Complete the implementation of bors, our new implementation of a merge queue bot for GitHub. It currently lacks support for performing merges (it can only perform so-called "try builds").
- Add support for interacting with the Rust team calendar through Zulip, using e.g. some kind of GitHub app bot.
- Add support for creating Zulip streams using the Rust team data repository.
- Implement a GitHub app for sync-team, our tool for managing permissions of Rust maintainers.
Expected result
Rust infrastructure management tools will receive new features, better documentation and tests.
Desirable skills
Intermediate knowledge of Rust. Familiarity with GitHub APIs is a bonus.
Project size
Medium.
Difficulty
Medium.
Mentors
Zulip streams
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
Zulip streams
Description
Today, developers can group Rust packages into a workspace to make it easier to operate on all of them at once.
However, cargo package and cargo publish do not support operating on workspaces (rust-lang/cargo#1169).
The goal of this project is to modify the Cargo build tool to add support for packaging and publishing Cargo workspaces.
Expected result
Milestone 1: cargo package can be run, with verification, with the standard package selection flags
Milestone 2: cargo publish can do the same as above, but also serially post the .crate files to the registry when done,
reporting to the user what was posted/failed if interrupted.
Desirable skills
Intermediate knowledge of Rust.
Project size
Medium.
Difficulty
Medium.
Mentor
Zulip streams
Description
The libc crate is one of the oldest crates of the Rust ecosystem, long predating
Rust 1.0. Additionally, it is one of the most widely used crates in the ecosystem (#4 most downloaded on crates.io).
This combinations means that the current version of the libc crate (v0.2) is very conservative with breaking changes and
remains backwards-compatible with all Rust compilers since Rust 1.13 (released in 2016).
The language has evolved a lot since Rust 1.13, and we would like to make use of these features in libc. The main one is
support for union types to proper expose C unions.
At the same time there, is a backlog of desired breaking changes tracked in this issue. Some of these come from the evolution of the underlying platforms, some come from a desire to use newer language features, while others are simple mistakes that we cannot correct without breaking existing code.
The goal of this project is to prepare and release the next major version of the libc crate.
Expected result
The libc crate is cleaned up and modernized, and released as version 0.3.
Desirable skills
Intermediate knowledge of Rust.
Project size
Medium.
Difficulty
Medium.
Mentor
Zulip streams
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
Medium to large.
Difficulty
Medium.
Mentor
Zulip streams
Related links
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.
It can currently catch ~60 different kinds of breaking changes, so there are hundreds of kinds of breaking changes it still cannot catch! The goal of this project is to extend its abilities, so that it can catch and prevent more breaking changes, by:
- adding more lints, which are expressed as queries over a database-like schema (playground)
- extending the schema, so more Rust functionality is made available for linting
Expected result
cargo-semver-checks will contain new lints, together with test cases that both ensure the lint triggers when expected
and does not trigger in situations where it shouldn't (AKA false-positives).
Desirable skills
Intermediate knowledge of Rust. Familiarity with databases, query engines, or query language design is welcome but not required.
Project size
Small to large (depends on how many lints will be implemented).
Difficulty
Small to medium (depends on the choice of implemented lints or schema extensions).
Mentor
Zulip streams
Related Links