This page contains a list of ideas for various projects that could help improve the Rust Project and potentially also the wider Rust community.
These project ideas can be used as inspiration for various OSS contribution programs, such as Google Summer of Code or OSPP.
This document contains ideas that should still be actual. Here you can also find a list of projects from GSoC runs:
We invite contributors that would like to participate in projects such as GSoC or that would just want to find a Rust project that they would like to work on to examine the project list and use it as an inspiration. Another source of inspiration can be the Rust Project Goals, particularly the orphaned goals. However, you can also work on these projects outside GSoC or other similar projects! We welcome all contributions.
If you would like to participate in GSoC, please read this. If you would like to discuss projects ideas or anything related to them, you can do so on our Zulip.
We use the GSoC project size parameters for estimating the expected time complexity of the project ideas. The individual project sizes have the following expected amounts of hours:
- Small: 90 hours
- Medium: 175 hours
- Large: 350 hours
- Rust Compiler
- Infrastructure
- Cargo
- Crate ecosystem
The list of ideas is divided into several categories.
Description
Recent OSS attacks such as the XZ backdoor have shown the importance of having reproducible builds.
Currently, the Rust toolchain distributed to Rust developers is not very reproducible. Our source code archives should be reproducible as of this pull request, however making the actual binary artifacts reproducible is a much more difficult effort.
The goal of this project is to investigate what exactly makes Rust builds not reproducible, and try to resolve as many such issues as possible.
While the main motivation is to make the Rust toolchain (compiler, standard library, etc.) releases reproducible, any improvements on this front should benefit the reproducibility of all Rust programs.
See Tracking Issue for Reproducible Build bugs and challenges for a non-exhaustive list of reproducibility challenges.
Expected result
Rust builds are more reproducible, ideally the Rust toolchain can be compiled in a reproducible manner.
Desirable skills
Knowledge of Rust and ideally also build systems.
Project size
Medium.
Difficulty
Hard.
Mentor
Zulip streams
Related links
Description
rustc_codegen_gcc uses rustc_codegen_ssa and implements the traits in this crate in order to have a codegen that plugs in rustc seamlessly.
Since rustc_codegen_ssa was created based on rustc_codegen_llvm, they are somewhat similar, which sometimes makes it awkward for the GCC codegen.
Indeed, some hacks were needed to be able to implement the GCC codegen with this API:
- Usage of unsafe
transmute: for instance, this or this. Fixing this might require separatingValueintoRValueandLValueor usingFunctionin place ofValuein some places to better fit the GCC API. - Usage of mappings to workaround the API: for instance, this or this.
Some other improvement ideas include:
- Separate the aggregate operations (structs, arrays): methods like
extract_valueare generic over structures and arrays because it's the same operation in LLVM, but it is different operations in GCC, so it might make sense to have multiple methods likeextract_fieldandextract_array_element. - Remove duplications between
rustc_codegen_gccandrustc_codegen_llvmby moving more stuff intorustc_codegen_ssa. For instance:- some debuginfo code is exactly the same
- ABI code
- the allocator code
- the dummy output type for inline assembly
- perhaps we could add a
set_alignmentmethod inrustc_codegen_ssathat asks the backend to set the alignment and is called inrustc_codegen_ssain strategic places so that we don't have to worry as much about alignment in the codegens (not sure if this is possible).
The goal of this project is to improve rustc_codegen_gcc by removing hacks, unnecessary unsafe code and/or code duplication with rustc_codegen_llvm by refactoring rustc_codegen_ssa.
It would be important that this refactoring does not result in a performance degradation for rustc_codegen_llvm.
Expected result
A rustc_codegen_gcc that contains less hacks, unsafe code and/or code duplication with rustc_codegen_llvm.
Desirable skills
Knowledge of Rust and basic knowledge of rustc internals, especially the codegen part.
Project size
Small-Medium depending on the chosen scope.
Difficulty
Medium.
Mentor
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
The std::arch module in the standard library provides architecture-specific intrinsic functions, which typically directly map to a single machine instruction.
Currently, it lives in its own repository outside the main Rust compiler repository (rustc). The rustc repository includes stdarch only as a submodule, and does not execute its testsuite on the compiler's CI. This sometimes causes contributor friction, because updates to the compiler can break stdarch (and vice versa) and it is not possible to change both the compiler and stdarch at once (in the same pull request).
stdarch has a comprehensive test suite that tests the intrinsics on several hardware architectures and operating system platforms, and it also includes fuzz tests. It cannot be simply copied over to rustc, because that has its own (much more complex) set of CI workflows. The stdarch testsuite thus has to be adapted to the way workflows are executed in the compiler repository.
The ultimate goal is to inline stdarch into rustc completely, and archive the stdarch repository. This can be incrementally achieved by the following two steps:
- Investigate the CI (continuous integration) test suite of
stdarch, and port as much of it intorustc. This will involve implementing new testing and documentation steps for working withstdarchin the compiler's build system, bootstrap. - Once a sufficient portion of the test suite has been ported,
stdarchshould be changed from a submodule to either a git or Josh subtree, so that compiler contributors are able to make changes tostdarchwhen they modify the compiler. This might involve creating some automation tooling to help with performing regular synchronizations from/tostdarch. See this page for more details.
Expected result
The most important parts of the stdarch test suite should be running in the CI of the Rust compiler. Ideally, stdarch should be included as a git/Josh subtree instead of a submodule, or in the best possible scenario moved completely into rust-lang/rust.
Desirable skills
Intermediate knowledge of Rust. Experience with GitHub Actions or CI workflows is a benefit.
Project size
Small to Medium.
Difficulty
Medium.
Mentors
Zulip streams
Description
Cargo maintains Bash and Zsh completions, but they are duplicated and limited in features.
A previous GSoC participant added unstable support for completions in Cargo itself, so we can have a single implementation with per-shell skins (rust-lang/cargo#6645).
There are many more arguments that need custom completers as well as polish in the completion system itself before this can be stabilized.
See
Expected result
Ideal:
- A report to clap maintainers on the state of the unstable completions and why its ready for stabilization
- A report to cargo maintainers on the state of the unstable completions and why its ready for stabilization
Desirable skills
Intermediate knowledge of Rust. Shell familiarity is a bonus.
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.
It can currently catch ~120 different kinds of breaking changes, meaning 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
Medium or large, depends on how many lints will be implemented. The more lints, the better!
Difficulty
Medium to high, depends on the choice of implemented lints or schema extensions.
Mentor
Zulip streams
Related Links