Development workflow

The day-to-day cycle for working on rust-lang/rust. See Getting started for first-time setup.

A typical iteration

# 1. Sync and start a feature branch
git fetch origin
git checkout -b fix-borrowck-msg origin/main

# 2. Make a change

# 3. Type-check (very fast)
./x check

# 4. Run a focused test
./x test tests/ui/borrowck/some-test.rs

# 5. If diagnostics changed intentionally, bless them
./x test tests/ui/borrowck/some-test.rs --bless

# 6. Run formatting + tidy locally
./x fmt
./x test tidy

# 7. Commit, push, open PR
git add -p
git commit -m "borrowck: improve diagnostic for borrow conflicts"
git push origin fix-borrowck-msg

For most compiler work, ./x check (cargo check on the compiler) is your fastest feedback loop. ./x build --stage 1 compiler (a few minutes) gets you a working stage-1 rustc, after which ./x test ... will use it automatically.

Commit etiquette

• One logical change per commit. Reviewers read by-commit.
• Subject line ≤ 72 chars, lowercase imperative ("borrowck: improve diagnostic", not "Improved diagnostic").
• Reference issue numbers in commit messages (Fixes #12345).
• For tracked stabilizations, include tracking issue references.
• Squash only when reviewers ask for it — Bors does not squash, so the commits you push are what appears in main.

Working with subtrees

The repository contains several subtrees pulled in via git subtree:

Path	Upstream
compiler/rustc_codegen_cranelift/	rust-lang/rustc_codegen_cranelift
compiler/rustc_codegen_gcc/	rust-lang/rustc_codegen_gcc
src/tools/clippy/	rust-lang/rust-clippy
src/tools/miri/	rust-lang/miri
src/tools/rustfmt/	rust-lang/rustfmt
src/doc/rustc-dev-guide/	rust-lang/rustc-dev-guide
library/stdarch/	rust-lang/stdarch
library/portable-simd/	rust-lang/portable-simd
library/compiler-builtins/	rust-lang/compiler-builtins
library/backtrace/	rust-lang/backtrace-rs

CONTRIBUTING.md recommends sending changes that don't accompany a compiler change directly to the upstream subtree repository. The subtree-tools-bot then pulls those changes into rust-lang/rust periodically. Submodules (cargo, rust-analyzer, etc.) work similarly.

If your PR has to span an upstream subtree and rust-lang/rust at once, it's still allowed — just expect more review back-and-forth.

Working with the merge queue

You don't merge your own PR. Once a reviewer has r+'d:

• bors schedules your PR into a queue.
• It runs the full CI matrix on your branch as if it were merged on top of main.
• If green, the merge commit goes to main (authored by bors@rust-lang.org, with your authorship in the commit body).
• If red, you get a S-waiting-on-author ping with the failure log.

Useful Bors commands (from PR comments):

• @bors r+ / @bors r=alice — approve and queue
• @bors r- — un-approve
• @bors try — run full CI without merging (used for perf/crater)
• @bors retry — re-run after a spurious failure
• @bors p=N — set priority (reserved for triage)
• @bors rollup=always|maybe|never|iffy — control batchability

See rust-bors.toml for the full configuration.

Performance- and ecosystem-impact runs

Two cross-cutting checks are sometimes requested by reviewers before merging:

• Perf run — @bors try @rust-timer queue builds the PR and runs the rustc-perf benchmark suite. Results appear at perf.rust-lang.org.
• Crater run — Bors team members can request a crater run, which builds every public crates.io crate against your PR and reports regressions.

Branches you'll see

• main — nightly, the only branch developers commit to.
• beta — promoted from main every 6 weeks, lives for 6 weeks.
• stable — promoted from beta. Frozen except for point releases.
• master — historical alias of main, no longer updated.
• Various try builds and perf branches — created and destroyed continuously by automation.

The relnotes-interest-group and relnotes label

If your PR is user-visible, add relnotes (the label) and a brief description in the PR body. The release manager harvests these for RELEASES.md at branch-cut time.