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.
In the list below, you can find projects from past 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, in particular the guidance around AI usage! If you would like to discuss project 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
- Crate ecosystem
The list of ideas is divided into several categories.
TPDE is a compiler framework that can act as a LLVM backend with very high build performance. Since slow build times are a constant issue for Rust developers, we would like to experiment with a TPDE-based backend for rustc, to see how much faster could compilation times get.
There are essentially two approaches that could be chosen here. Either use the TPDE-LLVM LLVM backend to generate assembly from LLVM IR emitted by rustc, or create a completely separate rustc backend that will work on TPDE IR (intermediate representation) directly and avoid going through LLVM.
The TPDE-LLVM-based approach is preferred since it should achieve most of the performance benefits, allows reusing LLVM plugins and infrastructure where desired, and is more likely to succeed. However, we will consider both approaches if the applicant can make good arguments in favor of a completely separate TPDE backend.
Note that this would be experimental work that would most likely have to live out-of-tree, at least at the beginning of the project.
Expected result
We have a new rustc experimental backend that can be used to compile non-trivial Rust programs (it does not have to be complete though, e.g. inline assembly support will probably not make the cut), and we can evaluate its performance e.g. on the Rust Compiler Benchmark Suite.
Desirable skills
Knowledge of Rust, basic familiarity with compiler functionality or LLVM is a bonus.
Project size
Large.
Difficulty
Medium to hard.
Mentor
Zulip streams
Description
The Rust compiler and its related infrastructure currently include a number of hiccups and roadblocks for Windows users specifically. This can make it more difficult for new contributors using Windows or one of the Unix-to-NT API translation layers (e.g. Cygwin, MSYS2, etc.), to get started with developing the compiler or even using Rust.
It is easy to stumble into rather weird bugs that are both difficult to debug and fix when compiling and working with Rust on Windows. For example, path normalization being done incorrectly for the host OS is a longtime pain point for Unix translation layers (e.g. MSYS2). Additionally, the "put libs wherever you want" strategy Windows has taken with system libraries makes it difficult to configure the build process correctly, especially where linking to external C libraries.
The standard library also has to work around some pecularities of the Windows API. For example, timing on Windows is based on 100ns increments since Jan 1st 1601, whereas most Unix platforms use milliseconds since Jan 1st 1970. In library code, this difference in API behavior is often not well documented and results in many developer surprises. For example, Checked arithmetic for adding a Duration smaller than 100ns results in a noop.
You can find a number of open issues related to Windows in the Rust issue tracker, by filtering for one of the many Windows target categories, for example O-windows.
Expected result
An overall improvement to the number of issues and hiccups/roadblocks a compiler developer or Rust user is expected to face when using Rust on Windows-based platforms.
Desirable skills
Familiarity with Rust, comfort working with large codebases and, depending on project scope, some of the following (non-exhaustive):
- Familiarity with Windows NT API
- Experience developing on Windows or a translation layer
- A decent amount of experience within your field(s)r of choice
Project size
Small to large. (Size is scalable, depending on the scope of the project.)
Difficulty
Medium to Hard, depending on the issues to be fixed.
Mentor
- Teapot (GitHub, Zulip)
- Teapot is happy to mentor projects fixing most compiler and ecosystem components, or any combination of them as the contributor details in their proposal.
- If you would like to do this project, please reach out so Teapot can tell you if he can mentor the field you would like to work on!
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 has accumulated a list of things to do in a 1.0 release. Additionally, some of the infrastructure for lib is rather outdated.
Most of the changes required for 1.0 are under the 1.0 milestone. 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.
Note: there was a project with a similar topic in GSoC 2025. But since there is a lot of work to be done, we have published this project idea again. The current idea description reflects the current state.
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. It's used by many of Rust's
most popular libraries — and even within cargo itself.
cargo-semver-checks can currently catch ~245 different kinds of breaking changes, meaning there are hundreds of kinds of breaking changes it
still cannot catch! Its largest capability gap is the inability to perform type-checking in lints, which is necessary
to detect the breakage between pub fn example(x: i64) {} and pub fn example(x: String) {}, for example.
The goal of this project idea is to design and implement the systems required to support the first batch of type-checking lints.
This specifically lays the ground work for shipping such lints by the hundreds — we're not looking to handle just a few special cases.
cargo-semver-checks has been adding hundreds of new lints per year,
and this will be the project that makes that possible for 2026 and beyond!
This would be a challenging "high risk, high reward" type of project: perfect for candidates looking to put forward
a significant amount of effort, determination, and skill toward a difficult problem with serious real world impact,
of course with support and guidance from a mentor. With luck and (quite a lot of) hard work, the culmination of
the project could even be shipping the first set of type-checking lints in a new cargo-semver-checks release.
Expected result
cargo-semver-checks will be able to catch the breakage in cases like:
- pub fn example(x: i64) {}
+ pub fn example(x: String) {}It will do so by using its declarative query language to notice the API change and capture information regarding it,
then plugging that information into a templating system able to generate a "witness" crate for the API change.
cargo-semver-checks would then automatically run cargo check on the witness crate, which will either pass
without errors (indicating no breakage), or error out indicating a breaking change.
A possible witness for the above example is:
pub fn witness(x: i64) {
crate_being_checked::example(x);
}
which will obviously only compile if the example() function takes an i64, not a String.
While this approach may seem overly complex at first, consider the following change:
- pub fn example(x: i64) {}
+ pub fn example(x: impl Into<i64>) {}This is a case where the type of x changed, but passing i64 still works fine — so this isn't a SemVer-major change.
Therefore, merely noticing that a type has changed is not sufficient to detect breakage, and we must use witness programs instead.
(It is highly impractical to use rustc as a library. It's similarly infeasible to reimplement the type-checker and trait solver ourselves.)
Desirable skills
Intermediate knowledge of Rust, or better. Familiarity with databases, query engines, code generation, or query language design is welcome but not required. Willingness to dive into a complex problem space and find your way around (with guidance, of course) is a must.
Contributors interested in this project idea are strongly encouraged to first familiarize themselves with cargo-semver-checks
and its linting system, which expresses lints as queries over a database-like schema (playground).
The project will require writing lints, extending the schema, writing code-generation code to create witness crates,
considering ways to improve performance in order to ensure a positive user experience, and designing the entire lint-writing process
such that type-checking lints are not challenging nor bespoke, but as normal and easy to write as any other lint.
Project size
Large
Difficulty
High
Mentor
Zulip streams
Related Links
- Playground where you can try querying Rust data
- GitHub issues describing not-yet-implemented lints
- Opportunities to add new schema, enabling new lints
- Query engine adapter
- Study of SemVer breakage in Rust, including more details on "witness" programs
- cargo-semver-checks 2025 year in review, where the "path forward" offers more info about this project idea
- Last year's GSoC project, which built the foundation for type-checking lints that we'd build upon