コントリビューション手順

バグ報告

バグは残念なものですが、ソフトウェアにおける現実です。 私たちは把握していないものを修正することはできないため、どうぞ積極的に報告してください。 何かがバグかどうか確信が持てない場合でも、遠慮なく issue を開いてください。

バグを公開で報告することが Rust ユーザーに対するセキュリティリスクになると考えられる場合は、 セキュリティ脆弱性を報告するための手順に従ってください。

nightly チャンネルを使用している場合は、バグを報告する前に、そのバグが 最新のツールチェーンにも存在するか確認してください。 すでに修正されている可能性があります。

可能であれば、バグを報告する前に [search existing issues] を行ってください。 他の誰かがすでにそのエラーを報告している可能性があるためです。 これは常にうまくいくとは限らず、何を検索すればよいか分かりにくい場合もあるため、 追加で行うとよいこと程度に考えてください。 誤って重複した報告を作成してしまっても問題ありません。

同様に、そのバグに遭遇した他の人があなたの issue を見つけやすくするために、 そのバグに固有である可能性のある情報を含む、説明的なタイトルで issue を作成することを検討してください。 それは、使用している言語機能またはコンパイラ機能、 バグを引き起こす条件、またはエラーメッセージがある場合はその一部などです。 例としては、戻り位置の impl Trait のライフタイム推論における “impossible case reached” が考えられます。

issue を開くには、[このリンク][create an issue]をたどり、提供されている適切なテンプレート内の フィールドに記入するだけです。

バグ修正または「通常の」コード変更

ほとんどの PR では、特別な手順は必要ありません。 単に open a PR すれば、それがレビューされ、承認され、マージされます。 これには、ほとんどのバグ修正、リファクタリング、その他のユーザーから見えない変更が含まれます。 次のいくつかのセクションでは、このルールの例外について説明します。

また、WIP PR や GitHub の Draft PRs を開くことはまったく問題ないことにも注意してください。 進めながらフィードバックを得たり、 共同作業者とコードを共有したりするために、これを好む人もいます。 また、PR のビルドとテストに CI を利用できるようにするためにこれを行う人もいます（たとえば、遅いマシンで開発している場合）。

新機能

Rust には強力な後方互換性の保証があります。 したがって、新機能を stable Rust に直接実装することはできません。 代わりに、stable、beta、nightly という 3 つのリリースチャンネルがあります。 Rust のトレインリリースモデルの詳細については、The Rust Book を参照してください。

• Stable: 一般的な利用向けの最新の安定版リリースです。
• Beta: 次のリリースです（6 週間以内に stable になります）。
• Nightly: リポジトリの main ブランチに従います。 これは、不安定な機能の利用が想定されている唯一のチャンネルであり、 その利用はオプトインの feature gate を通じて行われます。

詳細については、新機能の実装に関するこの章を参照してください。

破壊的変更

破壊的変更には、dev-guide 内に[専用のセクション][Breaking Changes]があります。

大規模な変更

コンパイラチームには、破壊的変更を引き起こすかどうかにかかわらず、大きな変更のための特別なプロセスがあります。 このプロセスは Major Change Proposal (MCP) と呼ばれます。 MCP は、コンパイラに対する大きな変更についてフィードバックを得るための、 比較的軽量な仕組みです（完全な RFC や、チームとの設計ミーティングとは対照的なものです）。

MCP が必要となる可能性のあるものの例には、大規模なリファクタリング、 重要な型への変更、コンパイラが何かを行う方法への重要な変更、 または小規模なユーザー向け変更が含まれます。

迷った場合は、on Zulip で質問してください。 最終的にマージされない PR に多くの労力を費やすのは 残念なことです！ MCP の詳細については、このドキュメントを参照してください。

パフォーマンス

コンパイラのパフォーマンスは重要です。 私たちはここ数年、それを徐々に改善することに多くの労力を注いできました。

あなたの変更がパフォーマンスの低下（または改善）を引き起こす可能性があると考えられる場合は、 “perf run” をリクエストできます（また、レビュアーも承認前にこれをリクエストする場合があります）。 これは、あなたの変更を含むコンパイラで ベンチマーク群をコンパイルする、さらに別のボットです。 数値はこちらに報告され、 あなたの変更を最新の main と比較して確認できます。

rustc 開発にも役立つ、一般的な Rust コードのパフォーマンス入門については、 The Rust Performance Book を参照してください。

プルリクエスト

プルリクエスト（略して PR）は、Rust を変更するために私たちが使用する主要な仕組みです。 GitHub 自体にも、Pull Request 機能の使用方法に関する優れたドキュメントがあります。 私たちは “fork and pull” モデルを使用しています。 このモデルでは、コントリビューターが自分の個人用 fork に変更を push し、プルリクエストを作成して それらの変更をソースリポジトリに取り込みます。 Rust へのコントリビューション時に Git を使用する方法についての章があります。

潜在的に大規模、複雑、横断的、かつ/または非常にドメイン固有な変更に関する助言

ローテーション中のコンパイラレビュアーは通常、それぞれがよく知っているコンパイラの領域を持っていますが、 あまり詳しくない領域もあります。あなたの PR に大規模、複雑、横断的、かつ/または非常にドメイン固有な変更が含まれている場合、 そのような PR のすべての変更を安心してレビューできる適切なレビュアーを見つけることは非常に困難になります。 これは、変更がコンパイラ固有のものだけでなく、標準ライブラリチームのような他チームのレビュアーの管轄に属する変更も含む場合にも当てはまります。 変更されたファイルに基づいて、関連するチームに通知し、特定のアラートを設定している人に ping する bot があります。

そのような変更を行う前に、提案する変更について事前にコンパイラチームと話し合うこと（および、その変更に承認が必要となる他のチームとも話し合うこと）を強く推奨します。また、コンパイラチームと協力して、潜在的にレビュー不能な大規模 PR を、個別にレビューしやすいより小さな PR の連続に分割できるかを検討してください。

提案する変更について話し合うには、Zulip に #t-compiler スレッドを作成してコンパイラチームと連絡を取ることができます。

事前にコンパイラチームと連絡を取ることは、いくつかの点で役立ちます。

1. PR が適時にレビューされる可能性が高まります。
   • 実際の PR を開く前に適切なレビュアーを特定する手助けをしたり、変更手続きを進めるためのアドバイザーやリエゾンを見つける手助けをしたり、必要に応じて try-job、perf 実行、crater 実行を行う手助けをしたりできます。
2. コンパイラチームがあなたの変更を追跡しやすくなります。
3. コンパイラチームは、変更の方向性がコンパイラチームの望む方向と一致しているかを確認するために、早い段階から頻繁にあなたの変更の感触を確認できます。
4. コンパイラチームが受け入れる意思のない大規模な変更に多大な時間と労力を費やしてしまう状況や、変更がコンパイラチームの同意しない方向であることに非常に遅い段階で気付く状況を避けるのに役立ちます。

ブランチを最新に保つ

rust-lang/rust の CI は、あなたのパッチを、ブランチの基点となっているコミットではなく、現在の main に対して直接適用します。 これにより、明示的なマージコンフリクトがない場合でも、 ブランチが古くなっていると予期しない失敗につながることがあります。

ブランチを更新するのは必要な場合だけにしてください。つまり、マージコンフリクトがある場合、上流の CI が壊れていてグリーンな PR を妨げている場合、またはメンテナーから要求された場合です。 必要がない限り、レビュー中のすでにグリーンな PR を更新することは避けてください。 レビュー中は、フィードバックに対応するためにインクリメンタルなコミットを作成してください。 squash や rebase は最後に行うか、レビュアーから要求された場合に行うことを推奨します。

更新する際は、git push --force-with-lease を使用し、何が変わったかを説明する簡潔なコメントを残してください。 一部のリポジトリでは、rebase の代わりに upstream/main からのマージを好みます。 プロジェクトの慣例に従ってください。 詳細な手順については、最新状態を保つを参照してください。

rebase 後は、CI が実行される前に問題を検出するために、関連するテストをローカルで実行することを推奨します。

r?

すべてのプルリクエストは別の人によってレビューされます。 @rustbot という bot があり、変更したファイルに基づいて、あなたのリクエストをレビューするランダムな人を自動的に割り当てます。

特定の人にプルリクエストのレビューを依頼したい場合は、 プルリクエストの説明またはコメントに r? を追加できます。 たとえば、@awesome-reviewer にレビューを依頼したい場合は、 プルリクエストの説明の末尾に次の内容を追加します。

r? @awesome-reviewer

すると、@rustbot はランダムな人ではなく、そのレビュアーに PR を割り当てます。 これは完全に任意です。

r? rust-lang/groupname と書くことで、特定のチームからランダムなレビュアーを割り当てることもできます。 例として、診断の変更を行っている場合は、 次の内容を追加することで診断チームからレビュアーを得ることができます。

r? rust-lang/diagnostics

指定可能な groupname の完全な一覧については、 [triagebot.toml 設定ファイル]の adhoc_groups セクション、 または [rust-lang チームデータベース]のチーム一覧を確認してください。

レビューを待つ

注記

プルリクエストのレビュアーは、多くの場合、作業量が上限に達しており、 その多くはボランティアとして貢献しています。 レビューの遅延を最小限に抑えるため、 プルリクエストの作成者と割り当てられたレビュアーは、レビューラベル （S-waiting-on-review と S-waiting-on-author）が最新に保たれるようにし、 適切なタイミングで次のコマンドを呼び出すべきです。

• @rustbot author: レビューは完了しており、 PR 作成者はコメントを確認し、それに応じて対応するべきです。

• @rustbot review: 作成者はレビューの準備ができており、 この PR はレビュアーのキューに再度入れられます。

レビュアーは人間であり、そのほとんどは空き時間に rustc に取り組んでいることに注意してください。 つまり、応答して PR をレビューするまでに時間がかかることがあります。 また、レビュアーが割り当てられた一部の PR を見逃す可能性もあるということです。

PR を前進させるために、Triage WG はレビュー待ちで、少なくとも 2 週間議論されていないすべての PR を定期的に確認しています。 2 週間以内にレビューを受けられない場合は、Zulip の #t-release/triage で Triage WG に遠慮なく尋ねてください。 彼らは、いつ ping すべきか、誰が休暇中かもしれないか、などを把握しています。

レビュアーは GitHub のコードレビューインターフェイスを使用して、いくつかの変更を要求することがあります。 一部の PR については、特別な手続きを要求することもあります。 そのような手続きの例については、Crater と [Breaking Changes] の章を参照してください。

CI

人間によるレビューに加えて、プルリクエストは継続的インテグレーション（CI）によって自動的にテストされます。 基本的に、プルリクエストを開いたり更新したりするたびに、 CI はコンパイラをビルドし、[compiler test suite] に対してテストし、さらにプルリクエストが Rust のスタイルガイドラインに準拠していることの確認など、他のテストも実行します。

継続的インテグレーションテストを実行することで、PR 作成者は最初のレビューサイクルを経ることなく早期にミスを発見でき、またレビュアーが特定のプルリクエストの状態を把握し続ける助けにもなります。 Rust には十分な CI キャパシティがあり、変更を push するたびに 計算リソースを無駄にすることを心配する必要はまったくありません。 また、生産性の向上に役立つのであれば、変更のテストに CI を使うことも まったく問題ありません（むしろ推奨されています！）。 特に、完全な ./x test スイートをローカルで実行することは推奨していません。 実行に非常に長い時間がかかるためです。 Rust の CI を使って変更をテストする方法については、Testing with CI の章を参照してください。

r+

誰かがあなたのプルリクエストをレビューした後、その人はプルリクエストに r+ という注釈を残します。 これは次のような見た目です。

@bors r+

これは、私たちの頼れるインテグレーションボットである @bors に、 あなたのプルリクエストが承認されたことを伝えます。 その後 PR は [merge queue] に入り、そこで @bors が 私たちのサポートするすべてのプラットフォームですべてのテストを実行します。 すべてうまくいけば、@bors はあなたのコードを main にマージし、プルリクエストを閉じます。

変更の規模によっては、少し異なる形式の r+ を目にすることがあります。

@bors r+ rollup

追加の rollup は、この変更を常に「ロールアップ」するべきであることを @bors に伝えます。 ロールアップされる変更は、処理を高速化するために、他の PR と一緒にテストおよびマージされます。 通常、互いに競合しないと見込まれる小さな変更だけが 「常にロールアップ」としてマークされます。

辛抱強く待ってください。 これには時間がかかる場合があり、キューが長くなることもあります。 また、PR が手動でマージされることは決してない点にも注意してください。

Opening a PR

これでプルリクエスト（PR）を提出する準備ができましたか？ すばらしいです！ 知っておくべき点がいくつかあります。

すべてのプルリクエストは、別のブランチを対象にすべきだと確実に分かっている場合を除き、 main ブランチに対して提出する必要があります。

PR を送信する前に、いくつかのスタイルチェックを実行してください。

./x test tidy --bless

このチェックは、すべてのプルリクエストの前に（またプルリクエスト内のすべての新しいコミットの前にも） 実行することを推奨します。 このチェックを忘れないように、push の前に [git hooks] を追加できます。 CI でも tidy が実行され、tidy が失敗すると CI も失敗します。

Rust は no merge-commit policy に従っています。 これは、マージコンフリクトに遭遇した場合、 マージではなく常にリベースすることが求められるという意味です。 たとえば、main ブランチの最新の変更を自分の feature ブランチに取り込むときは、 常に rebase を使用してください。 PR にマージコミットが含まれている場合、has-merge-commits としてマークされます。 たとえばインタラクティブリベースによってマージコミットを削除したら、再度そのラベルを 削除する必要があります。

@rustbot label -has-merge-commits

詳細については、この章を参照してください。

マージコンフリクトに遭遇した場合、またはレビュー担当者から何らかの 変更を求められた場合、PR は S-waiting-on-author としてマークされます。 それらを解決したら、@rustbot を使って S-waiting-on-review としてマークする必要があります。

@rustbot ready

GitHub では キーワードを使って issue を閉じることができます。 この機能は issue トラッカーを整然と保つために使用するべきです。 ただし、一般的には、 “closes #123” というテキストはコミットメッセージではなく PR の説明に入れることが好まれます。 特にリベース中に、コミット内で issue 番号を引用すると、該当する issue に 「スパム」を送ることになり得ます。

ただし、PR が stable-to-beta または stable-to-stable のリグレッションを修正し、 beta および/または stable へのバックポートが承認されている場合（つまり beta-accepted および/または stable-accepted としてマークされている場合）は、そのようなキーワードを 使用しないでください。修正が main に入った時点で、対応する issue が自動的に閉じられることを 望まないためです。 issue についてはどこかで言及したまま、PR の説明を更新してください。 たとえば、Fixes (after beta backport) #NNN. と書くことができます。

追加の対応として、タイトルが [beta] または [stable] で始まり、 対象の PR をバックポートする PR に十分注意してください。 その PR がマージされたら、関連する issue を閉じることができます。 閉じるコメントでは、関係したすべての PR に言及する必要があります。 issue を閉じる権限がない場合は、 元の PR にコメントを残し、レビュー担当者に代わりに閉じてもらうよう依頼してください。

Reverting a PR

PR が誤コンパイル、重大なパフォーマンスリグレッション、またはその他の重大な問題を引き起こす場合、 その PR をリグレッションテストケースとともに revert したいことがあります。 Forge docs の revert policy も確認できます （主にレビュー担当者向けですが、PR 作成者にとっても有用な情報が含まれています）。

PR に巨大な変更が含まれている場合、revert が難しくなり、その後の更新で インクリメンタルな修正をレビューすることが難しくなる場合があります。 また、その PR 内の特定のコードが後続の PR に大きく依存されている場合、 それを revert することが難しくなることがあります。

そのような場合は、#128271 に示されているように、問題のあるコードを特定し、一部の入力に対して無効化できます。

MIR 最適化については、#132356 に示されているように、 -Zunsound-mir-opt オプションを使って mir-opt をゲートすることもできます。

External dependencies

このセクションは “Using External Repositories” に移動しました。

Writing documentation

ドキュメントの改善は大歓迎です。 doc.rust-lang.org のソースは ツリー内の src/doc にあり、標準 API ドキュメントは ソースコード自体から生成されます（例: library/std/src/lib.rs）。ドキュメントのプルリクエストは、 他のプルリクエストと同じように機能します。

ドキュメント関連の issue を見つけるには、[A-docs label] を使用してください。

ドキュメントのスタイルガイドラインは [RFC 1574] にあります。

標準ライブラリのドキュメントをビルドするには、x doc --stage 1 library --open を使用します。 書籍（例: unstable book）のドキュメントをビルドするには、x doc src/doc/unstable-book. を使用します。 結果は build/host/doc に表示され、同時にデフォルトブラウザーで自動的に開かれるはずです。 詳細については、Building Documentation を参照してください。

小さな修正を確認するために、rustdoc を直接使用することもできます。 たとえば、rustdoc src/doc/reference.md は reference を doc/reference.html にレンダリングします。 CSS は乱れるかもしれませんが、HTML が正しいことは確認できます。

内部ドキュメントに対するタイポグラフィやスペルチェックの修正は受け付けていないことに注意してください。 通常、それは変更の churn やレビュー時間に見合わないためです。 内部ドキュメントの例としては、コードコメントや rustc api docs があります。 ただし、同じ PR 内の他の改善に伴う場合は、それらを修正しても構いません。

Contributing to rustc-dev-guide

Contributions to the [rustc-dev-guide] はいつでも歓迎されており、 [rust-lang/rustc-dev-guide リポジトリ][rdgrepo]で直接行うことができます。 そのリポジトリの issue tracker も、やるべきことを見つけるのに最適な方法です。 初心者向けの issue も、高度なコンパイラ開発者向けの issue もあります！

覚えておいてほしいことがいくつかあります：

• 過度に長い行はできるだけ避け、意味的な改行（各文の後で行を改行すること）を使用してください。 行の長さに厳密な制限はありません。 文または文の一部が、同じ行で自然な終わりまで続くようにしてください。

  これを支援するために、ci/sembr にあるツールを使用できます。 そのヘルプ出力は、次のコマンドで確認できます：

  cargo run --manifest-path ci/sembr/Cargo.toml -- --help
  

• ガイドにテキストをコントリビュートする場合は、何らかの期間 および/または理由を添えて情報に文脈を与え、読者がその情報をどの程度信頼すべきか分かるようにしてください。 適切な量の文脈を提供することを目指してください。たとえば、以下を含めることが考えられますが、これらに限定されません：

  • テキストが古くなっている可能性がある理由として、「変更」以外のもの。 変更はプロジェクト全体で常に起こるものだからです。

  • コメントが追加された日付。たとえば、「現在、…」 や 「現時点では、…」 と書く代わりに、次のいずれかの形式で日付を追加することを検討してください：

    • Jan 2021
    • January 2021
    • jan 2021
    • january 2021

    .github/workflows/date-check.yml には CI アクションがあり、 6 か月を超えているものを示す月次レポートを生成します （例）。

    アクションが日付を拾えるようにするには、日付を指定する前に特別なアノテーションを追加します：

    <!-- date-check --> Nov 2025
    

    例：

    As of <!-- date-check --> Nov 2025, the foo did the bar.
    

    日付を表示されるレンダリング結果の一部にすべきでない場合は、 代わりに次を使用してください：

    <!-- date-check: Nov 2025 -->
    

  • 関連する WG、tracking issue、rustc rustdoc ページ、または類似のものへのリンク。 変更プロセスの詳しい説明や、その情報が古くなっていないことを検証する方法を提供している可能性があります。

• テキストがかなり長くなった場合（数回ページスクロールする量を超える）や、複雑になった場合（4 つを超える サブセクションがある場合）は、先頭に目次を置くとよいかもしれません。 先頭に <!-- toc --> マーカーを含めることで自動生成できます。

⚠️ 注: rustc-dev-guide の変更をどこにコントリビュートするか

rustc-dev-guide の変更をどこにコントリビュートするか、およびそうすることの利点についての詳細は、 rustc-dev-guide チームのドキュメントを参照してください。

Issue トリアージ

https://forge.rust-lang.org/release/issue-triaging.html を参照してください。

rfcbot ラベル

rfcbot は、変更を承認または却下するなど、非同期の意思決定を調整するプロセスを追跡するために 独自のラベルを使用します。 これは RFCs、issue、pull request に使用されます。

役立つリンクと情報

このセクションは [“このガイドについて”] の章に移動しました。 [“About this guide”]: about-this-guide.md#other-places-to-find-information [search existing issues]: https://github.com/rust-lang/rust/issues?q=is%3Aissue [Breaking Changes]: bug-fix-procedure.md [triagebot.toml config file]: https://github.com/rust-lang/rust/blob/HEAD/triagebot.toml [rust-lang teams database]: https://github.com/rust-lang/team/tree/HEAD/teams [compiler test suite]: tests/intro.md [merge queue]: https://bors.rust-lang.org/queue/rust [git hooks]: https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks [A-docs label]: https://github.com/rust-lang/rust/issues?q=is%3Aopen%20is%3Aissue%20label%3AA-docs [RFC 1574]: https://github.com/rust-lang/rfcs/blob/master/text/1574-more-api-documentation-conventions.md#appendix-a-full-conventions-text [rustc-dev-guide]: https://rustc-dev-guide.rust-lang.org/ [rdgrepo]: https://github.com/rust-lang/rustc-dev-guide [create an issue]: https://github.com/rust-lang/rust/issues/new/choose