Rustへ貢献する — 言語、コンパイラ、標準ライブラリ

コンパイラと標準ライブラリのソースコードはメインレポジトリにあります。 メインレポジトリは主にそれらのメンテナンスのために存在しているので、イシュートラッカー上にあるラベルの多くはこれに関連したものです。 RustからLLVM IRへの変換についてのA-codegen、デバッガで使うためのメタデータ生成についてのA-debuginfo、エラー時にコンパイラーが提供するフィードバックについてのA-diagnostics、標準ライブラリの問題についてのA-libs、構文拡張に関連するA-macrosと A-syntaxext、型についてのA-typesystemなどが有益なラベルです。

コンパイラのアーキテクチャについてきちんとメンテナンスされているガイドはありませんがソースツリーに多少の概要はあります。 コンパイラを構成するクレートのAPIドキュメントもコードを読むときの指針となるでしょうし、同じくソースコードブラウザのRust DXRも参考になるはずです。 RustのテストスィートのガイドはRustのビルドシステムに馴染む方法を教えてくれますし、同様にmake tipsをコマンドラインから走らせても得られるものはあるでしょう。

近々入る予定のコンパイラの大きな変更に、内部でASTを直接操作することからMIRと呼ばれる中間表現を使うようにするものがあります。（訳注: 翻訳時点で既に入っています）。 この作業でコンパイラが単純化されるため様々な新たな可能性を開くことが期待されます。 例えばMIRベースの変換パスやMIRベースの最適化、インクリメンタルコンパイルなどです。 このため手助けが必要になります。 この作業に必要なまとまった情報源はありませんがinternals.rust-lang.orgや#rust-internalsで案内してもらいましょう。

コンパイラがクラッシュしたらばつが悪いですね — とても恐しい「コンパイラ内部のエラー(internal compiler error)」 (ICE)。 I-ICEラベルはこれらをトラックしており、大抵ありあまるほどあります。 これらは通常、とっかかりとしては良いバグです、何故なら直ったかどうかは簡単に分かりますし、比較的それ自身で完結することが多いからです。

RustのコードのパフォーマンスはRustの大きな長所の1つです。そしてRustコンパイラのパフォーマンスはRustの大きな短所の一つです。 実行時、あるいは — 特に — コンパイル時のパフォーマンスの改善はどんなものであっても歓迎されます。 I-slowやA-optimizationは実行時のパフォーマンスを、I-compiletimeはコンパイル時のパフォーマンスを扱います。 多数の負荷に対するコンパイル時間のパフォーマンスをトラックするサイトもあります。 コンパイラフラグの -Z time-passes はコンパイラパフォーマンスのデバッグに役立つでしょうし、RustのコードはLinuxの perf などの標準的なプロファイラでプロファイルが取れます。

大きな新機能はRequest for Comments (RFC)プロセスを通して採用されます。RFCでは設計への合意を取ります。 RFCは全員に開かれていますが、既に何度も協業をしている人と関わり合うプロセスなので徐々に関わることをお勧めします — 思い付きのRFCを歴史的、技術的、人的背景を理解せずに提出すると簡単に印象が悪くなり、人望を失うでしょう。 先程のREADMEファイルを読んでどういう仕組みかをしっかりと理解しましょう。 Rustの歴史の中で多数のアイディアが議論されてきており、拒絶されたものもあれば将来へ保留になったものありますし、RFCのイシュートラッカー上に言語に導入されようとしているアイディアの一覧があります。 RFCが受理され実装されることになる直前に「最後のコメント期間(final comment period)」と呼ばれるものに入ります。rust-lang/rfcsのfinal-comment-periodラベルがついているものがそれです。 同じように、安定版コンパイラで機能が有効にされる（「ungating」と呼ばれています）前にrust-lang/rustでfinal-comment-periodに入ります。 どちらのFCPも言語の方針へ関わったり意見を言ったりするための重要な期間であり、internals.rust-lang.orgのサブチームの週報で広報されます。

Rustのコンパイラエンジニアには#rustcで、言語設計者には#rust-langで、ライブラリの設計者には#rust-libsで会いましょう。