Getting Started
Thank you for your interest in contributing to Rust! There are many ways to contribute, and we appreciate all of them.
For general information about how to contribute to Rust, see Forge. The rest of this section is about how to contribute to the compiler specifically.
This documentation is not intended to be comprehensive; it is meant to be a quick guide for the most useful things. For more information, see How to build and run the compiler.
Finding help
See also “Asking Questions”.
Experts
Not all t-compiler members are experts on all parts of rustc;
it’s a pretty large project.
To find out who could have some expertise on
different parts of the compiler, consult triagebot assign groups.
The sections that start with [assign* in triagebot.toml file.
But also, feel free to ask questions even if you can’t figure out who to ping.
Another way to find experts for a given part of the compiler is to see who has made recent commits.
For example, to find people who have recently worked on name resolution since the 1.68.2 release,
you could run git shortlog -n 1.68.2.. compiler/rustc_resolve/.
Ignore any commits starting with
“Rollup merge” or commits by @bors (see CI contribution procedures for
more information about these commits).
What should I work on?
The rust monorepo is quite large and it can be difficult to know which parts need
help, or are a good starting place for beginners.
Here are some suggested starting places.
Easy or mentored issues
If you’re looking for somewhere to start, check out the following issue search. See the Triage for an explanation of these labels. You can also try filtering the search to areas you’re interested in. For example:
label:T-compilerwill only show issues related to the compilerlabel:A-diagnosticswill only show diagnostic issues
Not all important or beginner work has issue labels. See below for how to find work that isn’t labelled.
Recurring work
Some work is too large to be done by a single person. In this case, it’s common to have “Tracking issues” to co-ordinate the work between contributors. Here are some example tracking issues where it’s easy to pick up work without a large time commitment:
- Add recurring work items here.
If you find more recurring work, please feel free to add it here!
Diagnostic issues
Many diagnostic issues are self-contained and don’t need detailed background knowledge of the compiler. You can see a list of diagnostic issues here.
Picking up abandoned pull requests
Sometimes, contributors send a pull request, but later find out that they don’t have enough
time to work on it, or they simply are not interested in it anymore.
Such PRs are often eventually closed and they receive the S-inactive label.
You could try to examine some of these PRs and pick up the work.
You can find the list of such PRs here.
If the PR has been implemented in some other way in the meantime, the S-inactive label
should be removed from it.
If not, and it seems that there is still interest in the change,
you can try to rebase the pull request on top of the latest main branch and send a new
pull request, continuing the work on the feature.
Writing tests
Issues that have been resolved but do not have a regression test are marked with the E-needs-test label.
Writing unit tests is a low-risk,
lower-priority task that offers new contributors a great opportunity to familiarize themselves
with the testing infrastructure and contribution workflow.
You can see a list of needs test issues here.
Contributing to std (standard library)
See std-dev-guide.
Other ways to contribute
See Forge.
Cloning and Building
See “How to build and run the compiler”.
Contributor Procedures
This section has moved to the “Contribution Procedures” chapter.
Other Resources
This section has moved to the “About this guide” chapter.