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 and that were not yet completed. Here you can also find an archive of older projects from past GSoC events:
- Past Google Summer of Code projects
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 of 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
- Extend annotate-snippets with features required by rustc
- Reproducible builds
- Bootstrap of rustc with rustc_codegen_gcc
- Refactoring of rustc_codegen_ssa to make it more convenient for the GCC codegen
- ABI/Layout handling for the automatic differentiation feature
- Improving parallel frontend
- Prepare
stable_mircrate for publishing - C codegen backend for rustc
- Improve compiler UI test suite organization and usability
- Rust standard library
- Infrastructure
- Rustup
- Cargo
- rust-analyzer
- Crate ecosystem
The list of ideas is divided into several categories.
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 or hard.
Mentor
Zulip streams
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 used to be able to compile rustc and use the resulting compiler to successfully compile a Hello, World! program.
While it can still compile a stage 2 rustc, the resulting compiler cannot compile the standard library anymore.
The goal of this project would be to fix in rustc_codegen_gcc any issue preventing the resulting compiler to compile a Hello, World! program and the standard library.
Those issues are not known, so the participant would need to attempt to do a bootstrap and investigate the issues that arises.
If time allows, an optional additional goal could be to be able to do a full bootstrap of rustc with rustc_codegen_gcc, meaning fixing even more issues to achieve this result.
Expected result
A rustc_codegen_gcc that can compile a stage 2 rustc where the resulting compiler can compile a Hello, World! program using the standard library (also compiled by that resulting compiler).
An optional additional goal would be: a rustc_codegen_gcc that can do a full bootstrap of the Rust compiler. This means getting a stage 3 rustc that is identical to stage 2.
Desirable skills
Good debugging ability. Basic knowledge of:
- Intel x86-64 assembly (for debugging purposes).
rustcinternals, especially the codegen part.libgccjitand GCC internals.
Project size
Medium-Large depending on the chosen scope.
Difficulty
Hard.
Mentor
Zulip streams
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
Over the last year, support for automatic differentiation ('autodiff') was added to the Rust compiler. The autodiff tool which we are using (Enzyme) operates on LLVM-IR, which is the intermediate representation of code, used by LLVM. LLVM is the default backend of the Rust compiler. Unfortunately, two layout related problems limit its usability.
A) The Rust compiler has a set of ABI optimizations which can improve performance, but make it harder for autodiff to work. An example is the function fn foo(a: f32, b: f32) -> f32,
which the compiler might optimize to fn foo(x: i64) -> f32. While this is fine from an LLVM perspective, it makes it hard for Enzyme, the LLVM based autodiff tool.
More information about such optimizations can be found here.
If a function has a #[rustc_autodiff] attribute, the Rust compiler should simply not perform such optimizations. We don't want to disable these optimizations for all functions, as they are generally beneficial.
Multiple examples of function headers which will get handled incorrectly at the moment are listed here.
B) Enzyme requires good information about the memory layout of types, both to be able to differentiate the code, and to do so efficiently. In order to help Enzyme, we want to lower more Type Information from MIR or even THIR into LLVM-IR metadata, or make better usage of existing debug info. If you are interested in this part and also have some LLVM experience, please have a look at the LLVM website for the related proposal.
For both A) and B), the online compiler explorer here can be used to trigger both types of bugs, to get a feeling for existing problems.
Expected result
The Rust compiler should not perform ABI optimizations on functions with the #[rustc_autodiff] attribute. As a result, #[autodiff(..)] should be able to handle functions with almost arbitrary headers. If a general solution turns out tricky, it is ok to focus on the most common types like those listed in the issue above (e.g. combinations of floats, small arrays/structs/tuples, etc.). We care less about advanced types like those listed here. These changes can't have a performance impact on functions without the #[rustc_autodiff] attribute.
Newly working testcases should be added to the rust test suite. The rustc_autodiff parsing in the autodiff frontend might need small bugfixes if the new testcases discover additional bugs, but those can also be solved by other contributors.
Examples for code that currently is not handled correctly can be discussed in the project proposal phase.
Desirable skills
Intermediate knowledge of Rust. Familiarity with ABIs is a bonus, but not required.
Project size
Medium
Difficulty
Medium to hard.
Mentors
Zulip streams
Description
Improving compiler performance has always been a focus of the Rust community and one of the main tasks of the compiler team. Parallelization of rust compiler is an important and effective approach. Currently, the backend end (codegen part) of the compiler has been parallelized, which has brought a huge improvement in the performance of the compiler. However, there is still much room for improvement in the parallelization of the rust frontend.
The most important and valuable work in this area are two aspects:
A) Diagnosing and fixing deadlock issues caused by the execution order of compiler queries in a multithreaded environment.
Queries is a unique design of the Rust compiler, which is used to achieve incremental compilation process. It divides the compiler
process into various parts and caches the execution results of each part. However, queries caching dependencies between multiple threads may cause deadlock.
Work-stealing, a method used to improve parallelization performance, is the core reason.
To solve these problems, we need to find the part of the compiler process that causes deadlock through diagnosing coredumps in issues, and adjusting the execution order of this part of code so that there will be no circular dependencies on the query caches between multiple threads. This PR is a good example of solving a deadlock problem.
B) Improving the performance of the parallel frontend The parallel frontend has implemented parallelization in type checking, MIR borrow checking and other parts of the compiler. However, there is still a lot of room for improvement:
- HIR lowering. Modifying the array structure of
tcx.untracked.definitionsso that it can be accessed efficiently in multiple threads is likely to be the key. - Macro expansion. How to deal with the order problem of name resolution during macro expansion is a difficult problem.
- Lexing and/or parsing.
Achieving the above goals is of big significance to improving the performance of the Rust compiler.
The project could choose either one of these two areas, or try to tackle both of them together.
Expected result
Parallel frontend will not cause deadlock issues. We can ensure usability through UI testing.
The performance of the compiler will be improved, ideally at least by a couple of percentage points.
Desirable skills
Intermediate knowledge of Rust. A basic understanding of the implementation of the compiler process (such as typeck, hir_lowering, macro expansion) would be ideal.
Project size
Medium to hard (depending on the chosen scope).
Difficulty
Medium to hard.
Mentor
Zulip streams
Description
We are advancing the Rust compiler's StableMIR API, which provides a robust foundation for code analysis tool development. This API was specifically designed to shield developers from compiler internals, provide an intuitive interface, and to follow semantic versioning.
The project currently spans two key crates:
stable_mir: The public-facing API for tool developersrustc_smir: The internal bridge betweenstable_mirand the Rust compiler.
As we prepare to publish the stable_mir crate, we are seeking contributions in these critical areas:
- Refactor the dependency between
rustc_smirand thestable_mircrates in the compiler to help us prepare for releasingstable_mirv0.1. More details of this refactoring can be found here. - Implement a build time check on
stable-mircrate to warn users that are using an unsupported version of the compiler. - Improve test coverage and automation including CI improvements to test with different compiler versions.
- Create comprehensive developer documentation that covers maintenance procedures for both crates, ensuring future maintainers have clear guidelines for updates and compatibility management.
- Continue the StableMIR integration with MiniRust to help us assess and improve StableMIR as described in this issue.
Expected result
We are able to publish an initial version of the stable_mir crate that works across multiple nightly versions, and that gracefully fails if the version is not supported.
Desirable skills
- Good debugging ability.
- Basic knowledge of Rust.
- Basic knowledge of Github CI.
Project size
Medium-Large 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 Rust compiler (rustc) relies on large suites of integration tests to check its behavior. One of such test suite is the ui test suite (see tests/ui). The ui test suite has more than 18000 tests, and continues to grow, so it's important that it has a good organization and usability so contributors can find a test (at all) or identify possible test coverage for some feature/behavior.
However, there's a lot of tests in the ui test suite that suffer from suboptimal organization, naming and other kinds of deficiencies that make certain ui tests less effective than they could be. See Tracking Issue for ui test suite improvements #133895 for common issues and potential improvement ideas. The goal of this project is to improve the ui test suite's organization and usability.
The major challenge of this project is to identify how to improve certain ui tests without regressing test intent.
Expected result
Improved ui test suite organization and/or usability. Possible outcomes include but are not limited to:
- Fewer top-level tests immediately under (
tests/ui/), to be moved under more fitting subdirectories. - Some
uitests have improved test docs regarding test intention / references. - Some
uitests are adjusted to better serve their actual test intent.
See the tracking issue for more detailed descriptions of what more effective ui tests could look like.
Desirable skills
- Basic to intermediate knowledge of Rust.
- Basic knowledge of
gitand Github CI. - Basic familiarity with compiler internals is a bonus.
Project size
Medium to large (depending on the chosen scope).
Difficulty
Medium. However, that can vary depending on which ui tests and what improvements are attempted.
Mentor
Zulip streams
- Idea discussion
- Tracking issue discussion thread: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Discussion.20for.20ui.20test.20suite.20improvements.
Description
The std::arch module in the standard library provides architecture-specific intrinsic functions, which typically directly map to a single machine instruction.
These intrinsics are based on the architecture-specific intrinsics in C, which are usually based on a vendor specification and then implemented by C compilers such as Clang or GCC.
Rust supports thousands of intrinsics and we need to verify that they match the behavior of the equivalent intrinsics in C. A first step towards this has been the intrinsic-test which fuzz tests the ARM (AArch32 and AArch64) intrinsics by generating C and Rust programs which call the intrinsics with random data and then verifying that the output is the same in both programs.
While this covers the ARM architectures, we have thousands of intrinsics for other architectures (notably x86) which are only lightly tested with manual tests. The goal of this project is to extend intrinsic-test to other architectures: x86, PowerPC, LoongArch, etc.
Expected result
By the end of this project intrinsic-test should be able to validate the behavior of intrinsics on multiple architectures. The primary goal is to support x86 since this is the most widely used architecture, but stretch goals could include support for other architectures such as PowerPC, LoongArch, WebAssembly, etc.
Desirable skills
Intermediate knowledge of Rust and C. Knowledge of intrinsics or assembly is useful but not required.
Project size
Small to Medium.
Difficulty
Medium.
Mentors
Zulip streams
Description
There is a Rust project goal to
instrument the Rust standard library with safety contracts.
With this approach we are moving from informal comments specifying safety
requirements on unsafe functions to executable Rust code.
To prioritize which functions to equip with contracts first, we run a
verification contest in the
verify-rust-std fork.
In this contest,
challenges
have been put up that request specific sets of functions to be equipped with
contracts.
We also welcome new challenges being proposed by anyone, or contracts being
contributed outside any of the existing challenges.
For example, we are currently looking for contributions towards the following challenges:
- Verify the memory safety of core intrinsics using raw pointers
- Memory safety of BTreeMap's
btree::nodemodule - Safety of Methods for Atomic Types & Atomic Intrinsics
- Contracts for SmallSort
- Safety of
NonZero
There is, however, no restriction to contribute to just those challenges: any of the other open challenges are equally of interest, and so is creating new challenges.
Expected result
A set of safety contracts and harnesses have been implemented in verify-rust-std for one of the open challenges or any newly created challenge. A stretch goal is to port upstream as many of those contracts as possible.
Desirable skills
- Basic knowledge of Rust.
Project size
Small to Large, depending on the number of challenges being addressed.
Difficulty
Medium.
Mentor
Zulip streams
Description
Various Rust repositories under the rust-lang organization use a merge queue bot (bors) for testing and merging pull requests. Currently, we use a legacy implementation called homu, which is quite buggy and very difficult to maintain, so we would like to get rid of it. We have started the implementation of a new bot called simply bors, which should eventually become the primary method for merging pull requests in the rust-lang/rust repository.
The bors bot is a GitHub app that responds to user commands and performs various operations on a GitHub repository. Primarily, it creates merge commits and reports test workflow results for them. It can currently perform so-called "try builds", which can be started manually by users on a given PR to check if a subset of CI passed on the PR. However, the most important functionality, actually merging pull requests into the main branch, has not been implemented yet.
Expected result
bors can be used to perform pull request merges, including "rollups". In an ideal case, bors will be already usable on the rust-lang/rust repository.
Desirable skills
Intermediate knowledge of Rust. Familiarity with GitHub APIs is a bonus.
Project size
Medium.
Difficulty
Medium.
Mentors
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
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
We have taken a goal to
instrument the Rust standard library with safety contracts.
With this approach we are moving from informal comments specifying safety
requirements on unsafe functions to executable Rust code.
To prove that these safety requirements hold in all possible executions we need
to run static analysis tools.
We would further like to prove that these safety requirements continue to hold
despite code changes.
Therefore, we will want to run static analysis tools that prove these safety
requirements in continuous integration.
We have started such an effort in our
verify-rust-std fork.
Static analysis tools will typically require compute effort that may go up to minutes per function that needs to be proved. With a growing number of contracts we will, therefore, need to distribute proof effort across multiple nodes. We may, however, also reduce the proof effort when we can identify that any given proof necessarily continues to hold as the transitive closure of functions governed by the contract has not been modified since the proof last completed.
We are looking for contributions in the following areas:
- A reachability- or impact analysis that, given a code change, determines which proofs require re-verification. This will avoid wasting compute resources for unnecessary re-verification.
- A system that will shard proofs across multiple nodes and recombine their results. Multiple verification tools may be involved, and tools may have varying performance characteristics. Load balancing could conceivably be done in a dynamic fashion (where communication between nodes is required, but this may be hard to accomplish with GitHub runners), or per a pre-computed distribution (mapping pre-defined sets of verification tasks to runners). In the latter (and likely more feasible) scenario the distribution should be easy to adjust via configuration files for we expect the set of verification tasks to change over time.
Expected result
A system that can reliably run all verification tasks within a time limit (where that time limit needs to be determined empirically), and for changes that do not impact any contract no actual verification tool is invoked.
Desirable skills
- Intermediate knowledge of Rust.
- Basic knowledge of Github CI.
Project size
Medium.
Difficulty
Medium.
Mentor
Zulip streams
Description
rustup is an indispensable part of Rust's infrastructure, as it provides easy access to a Rust toolchain to millions of Rust users.
When installing a toolchain, it first downloads a set of components and then extracts them to disk. Currently, all downloads and disk I/O is performed serially, which makes rustup slower than it could be. Ideally, it should be able to overlap network downloads with disk I/O, and potentially also perform multiple network downloads at once.
Making rustup faster could have a high impact on the Rust ecosystem, particularly in CI environments, where rustup is typically used to download a Rust toolchain in every workflow execution. Since there are tens of thousands of repositories that use Rust in their CI, this can add up quickly.
There has been a prior experiment that showed that concurrent rustup could in fact provide non-trivial performance improvements. This issue contains discussion on the topic.
The rustup codebase now uses async, which should make implementing concurrent network and disk operations simpler.
The goal of the project is to add concurrency to rustup to enable overlap od network and disk I/O operations and perform benchmarks and experiments to evaluate what is the performance effect of such a change and when it is even worth it to perform it.
Expected result
Rustup will be able to overlap network and disk I/O and perform network requests concurrently.
Desirable skills
Intermediate knowledge of Rust. Familiarity with async programming or cross-platform filesystem knowledge is a bonus.
Project size
Medium.
Difficulty
Medium.
Mentor
Zulip streams
Related Links
Description
Some compiler errors know how to fix the problem and cargo fix is the command for applying those fixes.
Currently, cargo fix calls into the APIs that implement cargo check with
cargo in a way that allows getting the json messages from rustc and apply
them to workspace members.
To avoid problems with conflicting or redundant fixes, cargo fix runs rustc for workspace members in serial.
As one fix might lead to another, cargo fix runs rustc for each workspace member in a loop until a fixed point is reached.
This can be very slow for large workspaces.
We want to explore an alternative architecture where cargo fix runs the
cargo check command in a loop,
processing the json messages,
until a fixed point is reached.
Benefits
- Always runs in parallel
- May make it easier to extend the behavior, like with an interactive mode
Downsides
- Might have issues with files owned by multiple packages or even multiple build targets
This can leverage existing CLI and crate APIs of Cargo and can be developed as a third-party command.
See cargo#13214 for more details.
Expected result
- A third-party command as described above
- A comparison of performance across representative crates
- An analysis of corner the behavior with the described corner cases
Desirable skills
Intermediate knowledge of Rust.
Project size
Medium
Difficulty
Medium.
Mentor
Zulip streams
Description
Cargo is a high-level, opinionated command. Instead of trying to directly support every use case, we want to explore exposing the building blocks of the high-level commands as "plumbing" commands that people can use programmatically to compose together to create custom Cargo behavior.
This can be prototyped outside of the Cargo code base, using the Cargo API.
See the Project Goal for more details.
Expected result
Ideal: a performant cargo porcelain check command that calls out to
individual cargo plumbing <name> commands to implement its functionality.
Depending on the size the participant takes on and their experience, this may be out of reach. The priorities are:
- A shell of
cargo porcelain check - Individual commands until
cargo porcelain checkis functional - Performance
Desirable skills
Intermediate knowledge of Rust.
Project size
Scaleable
Difficulty
Medium.
Mentor
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
When developers need to extend how Cargo builds their package, they can write a build script. This gives users quite a bit of flexibility but
- Allows running arbitrary code on the users system, requiring extra auditing
- Needs to be compiled and run before the relevant package can be built
- They are all-or-nothing, requiring users to do extra checks to avoid running expensive logic
- They run counter to the principles of third-party build tools that try to mimic Cargo
A developer could make their build script a thin wrapper around a library (e.g. shadow-rs) but a build script still exists to be audited (even if its small) and each individual wrapper build script must be compiled and linked. This is still opaque to third-party build tools.
Leveraging an unstable feature, artifact dependencies, we could allow a developer to say that one or more dependencies should be run as build scripts, passing parameters to them.
This project would add unstable support for build script delegation that can then be evaluated for proposing as an RFC for approval.
See the proposal for more details.
Expected result
Milestones
- An unstable feature for multiple build scripts
- An unstable feature for passing parameters to build scripts from
Cargo.toml, built on the above - An unstable feature for build script delegation, built on the above two
Bonus: preparation work to stabilize a subset of artifact dependencies.
Desirable skills
Intermediate knowledge of Rust, especially experience with writing build scripts.
Project size
Large.
Difficulty
Medium.
Mentor
Zulip streams
Description
Today, rust-analyzer (and RustRover) expands proc-macros by spawning a separate proc-macro server process that loads and executes the proc-macro dynamic libraries. They communicate to this process via a JSON RPC interface that has not been given much thought when it was implemented, now starting to show its limitations.
The goal is to replace this current implementation entirely in favor of a more performant format that also supports the more complicated needs of the proc-macro API, outlined in rust-lang/rust-analyzer#19205.
Expected result
There exists a new proc-macro server that is more efficient and allows for implementing the remaining proc-macro API. Ideally, it should be integrated within rust-analyzer.
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
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 crate used for testing libc (ctest) uses an old syntax parser that cannot support modern Rust, so some of the
changes will require rewriting ctest to use a newer parser (e.g. syn). This upgrade is tracked at
rust-lang/libc#4289.
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.
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
- 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
Description
As more lints get added to cargo-semver-checks, its runtime grows longer.
As a result, users' iteration loops and CI pipelines take longer as well, degrading the overall experience of using the tool.
Figure out ways to speed up cargo-semver-checks, and find good ways to deploy them without degrading the maintainability of the codebase!
Expected result
The wall-clock runtime of running cargo-semver-checks on a large Rust crate gets cut by 50-80%, while still running the same lints as before.
Desirable skills
Interest in and at least a bit of experience with performance engineering. Understanding of how to apply techniques like:
- profiling and benchmarking
- parallel programming (e.g. with
rayon) - building and applying indexes (in the database sense)
Strong attention to detail. Willingness to learn quickly and perform lots of experiments, even though many of them may prove to be dead ends. Discipline and thoughtfulness when writing and testing code, to ensure that code changes are not merely fast but also maintainable.
Project size
Ideally large, to have the biggest possible positive performance impact.
Difficulty
Medium to high. See the "desirable skills" section above.
Mentor
Zulip streams
Related Links
- Playground where you can try querying Rust data
- Past optimization work: Speeding up Rust semver-checking by over 2000x
- Conference talk: How Database Tricks Sped up Rust Linting Over 2000x
- Query engine adapter, where many of the optimizations may be deployed
Description
When cargo-semver-checks reports a breaking change, it in principle has seen enough information for the breakage to be reproduced with an example program: a witness program.
Witness programs are valuable as they confirm that the suspected breakage did indeed happen, and is not a false-positive.
Expected result
Automatic witness generation is something we've explored, but we've only scratched the surface at implementing it so far.
The goal of this project would be to take it the rest of the way: enable cargo-semver-checks to (with the user's opt-in) generate witness programs for each lint, verify that they indeed demonstrate the detected breakage, and inform the user appropriately of the breakage and the manner in which it was confirmed.
If a witness program fails to reproduce breakage flagged by one of our lints, we've found a bug — the tool should then prepare a diagnostic info packet and offer to help the user open an auto-populated GitHub issue.
Stretch goal: having implemented witness generation, run another study of SemVer compliance in the Rust ecosystem, similar to the study we completed in 2023. The new study would cover many more kinds of breaking changes, since cargo-semver-checks today has 2.5x times more lints than it did back then. It would also reveal any new false-positive issues, crashes, or other regressions that may have snuck into the tool in the intervening years.
Desirable skills
Intermediate knowledge of Rust. Interest in building dev tools, and empathy for user needs so we can design the best possible user experience. Familiarity with databases, query engines, or programming language design is welcome but not required.
Project size
Large
Difficulty
Medium
Mentor
Zulip streams
Related Links
- Playground where you can try querying Rust data
- Use of witness programs to verify breaking change lints
Description
The Wild linker is a project to build a very fast linker in Rust that has incremental linking and hot reload capabilities.
It currently works well enough to link itself, the Rust compiler, clang (provided you use the right compiler flags) and a few other things. However, there are various features and combinations of flags that don’t yet work correctly. Furthermore, we have a pretty incomplete picture of what we don’t support.
The proposed project is to run the test suite of other linkers with Wild as the linker being tested, then for each failure, determine what the problem is. It’s expected that many failures will have the same root cause.
Expected result
Write a program, ideally in Rust, that runs the test suite of some other linker. Mold’s test suite is pretty easy to run with Wild, so that’s probably a good default choice. The Rust program should emit a CSV file with one row per test, whether the test passes or fails and if it fails, an attempt to identify the cause based on errors / warnings emitted by Wild.
For tests where Wild doesn’t currently emit any error or warning that is related to the cause of the test failure, attempt to make it do so. Some of the tests might fail for reasons that are hard to identify. It’s OK to just leave these as uncategorised. Where tests fail due to bugs or differences in behaviour of Wild, automatic classification likely isn’t practical. A one-off classification of these would be beneficial.
If time permits, pick something achievable that seems like an important feature / bug to support / fix and implement / fix it.
Desirable skills
Knowledge of Rust. Any existing knowledge of low-level details like assembly or the ELF binary format is useful, but can potentially be learned as we go.
Project size
Small to large depending on chosen scope.
Difficulty
Some of the work is medium. Diagnosing and / or fixing failures is often pretty hard.
Mentor
Zulip streams
Further resources