Fun facts

A handful of things about this codebase that are interesting once you know to look for them.

The compiler is bootstrapped — and the build system is too

rustc is written in Rust, so building it requires a Rust compiler. The repository uses a "stage 0" precompiled compiler downloaded from static.rust-lang.org (pinned in src/stage0) to build the stage 1 compiler, which then builds the stage 2 (final) compiler.

Less famously: the build system is also bootstrapped. The Rust binary in src/bootstrap/ cannot run before there's a Rust compiler, so src/bootstrap/bootstrap.py (a 54 KB Python script) downloads stage 0 first and uses it to build the bootstrap binary. From that point on, all build logic is Rust. See src/bootstrap/README.md for the gory detail.

RELEASES.md is a 900 KB file

RELEASES.md is the canonical changelog going back to Rust 1.0 (May 2015). It's about 895 KB of plain Markdown. Every stable release since 1.0 has an entry. New releases are appended via a tool: src/tools/replace-version-placeholder and the release-train scripts.

triagebot.toml is bigger than most source files

triagebot.toml is ~53 KB of YAML/TOML configuration controlling automatic PR assignment, label management, ping groups, FCP automation, and team mention rules. It's larger than nearly every individual .rs file in the compiler.

tests/crashes/ exists because the tests crash

Most test directories contain code that should compile correctly. tests/crashes/ is the opposite: it's a directory of files that currently trigger an Internal Compiler Error (ICE). When a fix lands and a crashing input no longer crashes, the file is moved to tests/ui/ with the bug-number filename. It's the closest thing in this repo to a "graveyard of bugs."

There are at least three codegen backends in this repo

The default backend, rustc_codegen_llvm, drives the in-tree LLVM at src/llvm-project/. But rustc_codegen_cranelift (fast debug-mode codegen) and rustc_codegen_gcc (a libgccjit-based backend) live alongside it. Backends are loaded as dynamic libraries at startup; you can pick one with -Zcodegen-backend.

Miri and CTFE are the same engine

Compile-time const fn evaluation runs the MIR interpreter in compiler/rustc_const_eval/. The miri tool (src/tools/miri/) takes that same interpreter, points it at runtime code, and adds undefined-behavior detection — same engine, different aliasing rules. So when const fn evaluation gets a new feature, Miri usually inherits it for free.

compiler/rustc/src/main.rs is forty lines and does almost nothing

Everything interesting in the compiler is in rustc_driver_impl and the dozens of rustc_* crates it pulls in. The actual rustc binary's main.rs (compiler/rustc/src/main.rs) is a 40-line file whose body is essentially rustc_driver::main(). Most of its lines are comments explaining why it links jemalloc the way it does.

The standard library has its own bootstrap

Building std requires core and alloc, which reference compiler-builtins for things like __udivdi3 (long division on 32-bit targets). The crate library/compiler-builtins/ is itself a vendored subtree from rust-lang/compiler-builtins. So the standard library has its own miniature dependency stack that must compile before std can.

The workspace Cargo.toml deliberately excludes some crates

The root Cargo.toml lists ~45 members but explicitly excludes compiler/rustc_codegen_cranelift, compiler/rustc_codegen_gcc, src/bootstrap, and tests/rustdoc-gui. Each excluded crate has its own self-contained Cargo workspace, because they need different toolchains, dependencies, or configurations than the main tree.

bootstrap.example.toml is documentation that is also a config file

bootstrap.example.toml is ~50 KB of fully-commented example configuration — every option bootstrap understands, with an explanation, with each line #-prefixed so the file is also a valid TOML. You can copy it to bootstrap.toml and uncomment the lines you want.

x.py works on three operating systems with three different shims

To handle the three native scripting environments, the same entry point exists three times:

• x — POSIX shell wrapper (Unix)
• x.ps1 — PowerShell wrapper (Windows)
• x.py — pure Python (cross-platform fallback)

All three find a Python interpreter and invoke src/bootstrap/bootstrap.py. The x and x.ps1 shims exist mainly to save you typing python or python3.