Contributing to Rust — language, compiler, and the standard library
The source code to the compiler and standard library are in the main repository, and as their maintenance is the primary objective of that repository, many labels on the issue tracker relate to it. Some of the more fruitful labels include A-codegen, for translation of Rust to LLVM IR; A-debuginfo, generation of metadata used by debuggers; A-diagnostics, the feedback the compiler provides on errors; A-libs, issues with the standard library; A-macros and A-syntaxext, both related to syntax extensions; and A-typesystem, on the topic of types.
There is no well-maintained guide to the architecture of the compiler,
but there is a small overview in-tree. The API
documentation for the crates that make up the
compiler can help with navigating the code, as can
the source code browser Rust DXR. The guide to the Rust test
suite will teach you how to exercise the Rust build system
effectively, as will running make tips at the command line.
For the foreseable future, one of the major thrusts of Rust compiler development is converting its internals from operating directly off the AST to working with an intermediate representation called MIR. This work is expected to open up many new possibilities by simplifying the compiler and help is needed to e.g. create a MIR-based translation pass, add MIR-based optimizations, and implement incremental compilation. There is yet no single source for information on work needed here, but ask on internals.rust-lang.org or #rust-internals for guidance.
It’s embarrasing when our compiler crashes — the dreaded ‘internal compiler error’ (ICE). The I-ICE label tracks these, and they are often plentiful. These are usually good bugs to start with because it’s easy to know when you’ve fixed them, and they’re often relatively self-contained.
The performance of Rust code is one of its great advantages; and the
performance of the Rust compiler one of its great weaknesses. Any
improvements to either runtime or — especially — compiletime performance
are widely celebrated. The I-slow and A-optimization labels deal
with runtime performance, and I-compiletime with compiletime. We have
a site that tracks compiletime performance on a number
of workloads. The -Z time-passes compiler flag can help debug
compiler performance, and Rust code can be profiled with standard
profilers like perf on Linux.
Major new features go through a Request for Comments (RFC) process, by which the design is agreed upon. Though it is open to all, it is a social process between developers who already have various amounts of experience working together, and it is recommended to get involved slowly — submitting a hasty RFC without understanding the historical, technical, or social context is an easy way to make a poor impression and come away disappointed. Read the aforelinked readme file to understand best how it all works. Many ideas have been debated in Rust’s history, some rejected, some postponed until the future, and the RFC issue tracker catalogs some wishlist ideas that have yet to make headway into the language. Shortly before an RFC is accepted for implementation it enters ‘final comment period’, indicated by the final-comment-period label on the rust-lang/rfcs repository. Likewise, before a feature is enabled in the stable compiler (called ‘ungating’) it enters final-comment-period in the rust-lang/rust repository. Both FCPs are critical moments to get involved and express opinions on the direction of the language, and are advertised in the weekly subteam reports on internals.rust-lang.org.
Meet other Rust compiler engineers in #rustc, language designers in #rust-lang, and library designers in #rust-libs.