为 Rust 出力 — 语言、编译器和标准库

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.

当我们的编译器崩溃时，这很尴尬 — 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. 我们有一个在一些工作流上跟踪编译性能的网站。 -Z time-passes 编译器标志可以帮助调试编译器性能， Rust 代码在 Linux 上也能用 perf 之类的标准分析器分析。

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.

在 #rustc 中能遇到其他 Rust 编译器工程师，语言设计师在 #rust-lang，库设计员在 #rust-libs。