Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

安定化のリクエスト

注記: このページは言語機能の安定化について説明しています。 ライブラリ機能の安定化については、ライブラリ機能の安定化を参照してください。

不安定機能が十分にテストされ、未解決の懸念がなくなったら、誰でもその安定化を推進できますが、その機能に携わってきた人々を関与させるのが賢明です。 以下の手順に従ってください。

必要であれば RFC を書く

その機能が lang experiment の一部であった場合、lang チームは一般に、安定化の前にまず RFC を受理したいと考えます。

ドキュメント PR

その機能は Unstable Book に文書化されている可能性があり、これは src/doc/unstable-book にあります。 feature gate のページが存在する場合は削除してください。 そのドキュメントの有用な部分を他の場所に統合してください。

ドキュメントの更新が必要になる可能性がある場所は次のとおりです。

  • The Reference: これは完全な詳細を含めて更新しなければならず、安定化をマージできるようになる前に、lang-docs チームのメンバーが PR をレビューして承認しなければなりません。
  • 判断に迷う場合は、このリポジトリで issue を開いてください。そこで議論できます。
  • 標準ライブラリドキュメント: これは必要に応じて更新されます。 言語機能では多くの場合これは不要ですが、? が言語に追加されたときのように、慣用的な例の書き方を変える機能であれば、ライブラリドキュメント内のこれらを更新することが重要です。 また、標準ライブラリ内のキーワードドキュメントと ABI ドキュメントも確認してください。これらは言語の変更に応じて更新が必要になる場合があります。

上記のリポジトリについて、この新機能に関するドキュメントを更新する PR を準備してください。 これらのリポジトリのメンテナーは、安定化プロセス全体が完了するまで、これらの PR をオープンのままにしておきます。 その間に、次の手順に進むことができます。

安定化レポートを書く

このリポジトリにあるテンプレートを使用して安定化レポートを作成してください。

安定化レポートは以下を要約します。

  • RFC が受理されてからの主要な設計上の決定と逸脱。これには、FCP された、または言語チームによって他の形で受理された決定と、lang チームに初めて提示されるものの両方が含まれます。
    • 多くの場合、最終的に安定化される言語機能には、元の RFC から大きな設計上の逸脱があります。 それは問題ありませんが、これらの逸脱は明確に示し、慎重に説明しなければなりません。
  • RFC が受理されてから行われた作業。言語機能の前進を支えた主要なコントリビューターを明記します。

Stabilization Template には、この機能と lang のサブチーム（例: types、opsem、lang-docs など）との関連を明らかにし、見落とされがちな項目を特定することを目的とした一連の質問が含まれています。

安定化レポートは通常、安定化 PR のメインコメントとして投稿されます（次のセクションを参照）。

安定化 PR

機能はそれぞれ異なり、このガイドで説明している内容を超える手順が必要になる場合もあります。

lang チームが安定化を検討する前に、その機能を説明する The Reference への完全な PR が存在していなければならず、安定化 PR がマージされる前に、その PR は lang-docs チームによってレビューされ、承認されていなければなりません。

feature-gate 一覧の更新

不安定な feature-gate の中央一覧は compiler/rustc_feature/src/unstable.rs にあります。 declare_features! マクロを検索してください。 安定化しようとしている機能のエントリがあるはずです。 たとえば次のようなものです（rust-lang/rust#32409 から引用）。

// pub(restricted) 可視性 (RFC 1422)
(unstable, pub_restricted, "CURRENT_RUSTC_VERSION", Some(32409)),

上記の行は compiler/rustc_feature/src/accepted.rs に移動する必要があります。 declare_features! 呼び出し内のエントリはソートされているため、正しい場所を見つけてください。 完了すると、次のようになります。

// pub(restricted) 可視性 (RFC 1422)
(accepted, pub_restricted, "CURRENT_RUSTC_VERSION", Some(32409)),
// これを変更したことに注意

（過去の変更のファイル内でバージョン番号を見かけることになりますが、安定化が行われると予想する rustc バージョンを入れるべきではありません。代わりに CURRENT_RUSTC_VERSION を使用してください。）

feature-gate の既存の使用箇所の削除

次に、コードベース内で機能文字列（この場合は pub_restricted）を検索し、それが出現する場所を見つけます。 std および任意の rustc クレート内の #![feature(XXX)] の使用箇所を （これには library/ および compiler/ 配下のテストフォルダーが含まれますが、トップレベルの tests/ は含まれません） #![cfg_attr(bootstrap, feature(XXX))] に変更してください。 これにより、feature-gate は stage1 にのみ含まれます。stage1 は現在のベータを使用してビルドされます（これは、その機能が現在のベータではまだ不安定であるために必要です）。

また、テスト（例: tests/ 配下）からそれらの文字列を削除してください。feature-gate を特に対象とするテスト（つまり、その機能を使うには feature-gate が必要であることだけをテストし、それ以外は何もテストしないもの）がある場合は、そのテストを単に削除してください。

その機能の使用に feature-gate を要求しない

最も重要なのは、feature-gate が存在しない場合にエラーを示すコードを削除することです（その機能は現在では安定していると見なされるためです）。 その機能が何らかの新しい構文を使用するために検出できる場合、そのコードの一般的な場所は compiler/rustc_ast_passes/src/feature_gate.rs です。 たとえば、次のようなコードが見つかるかもしれません。

gate_all!(pub_restricted, "`pub(restricted)` 構文は実験的です");

gate_all! マクロは、pub_restricted 機能が有効になっていない場合にエラーを報告します。 pub(restricted) が安定した現在では、これは不要です。

より微妙な機能については、次のようなコードが見つかる場合があります。

if self.tcx.features().async_fn_in_dyn_trait() { /* XXX */ }

この pub_restricted フィールド（機能にちなんで名付けられたもの）は、通常、feature flag が存在しない場合は false、存在する場合は true になります。 そのため、そのフィールドが true であると仮定するようにコードを変換してください。 この場合、それは if を削除し、/* XXX */ だけを残すことを意味します。

if self.tcx.sess.features.borrow().pub_restricted { /* XXX */ }
これは次のようになります
/* XXX */

if self.tcx.sess.features.borrow().pub_restricted && something { /* XXX */ }
 これは次のようになります
if something { /* XXX */ }

チームのノミネート

安定化 PR を開くときは、lang チームとそのアドバイザー（@rust-lang/lang @rust-lang/lang-advisors）、およびその機能に関連するその他のチームを CC してください。例:

  • @rust-lang/types: 型システムとの相互作用について。
  • @rust-lang/opsem: unsafe コードとの相互作用について。
  • @rust-lang/compiler: 実装の堅牢性について。
  • @rust-lang/libs-api: 標準ライブラリ API またはその保証に対する変更について。
  • @rust-lang/lang-docs: これを Reference でどのように文書化すべきかに関する質問について。

安定化レポートとともに安定化 PR が開かれたら、すぐに寄せられるコメントを少し待ってください。 そのようなコメントが「落ち着いて」、その PR を lang チームが検討する準備ができたと感じたら、今後の lang ミーティングで検討される議題に載せるために、PR をノミネートしてください。

あなたが rust-lang organization のメンバーでない場合は、割り当てられたレビュアーに、あなたに代わって関連チームを CC するよう依頼できます。

PR で FCP を提案する

lang チームやその他の関連チームが安定化をレビューし、彼らからの質問があればそれに回答した後、いずれかのチームのメンバーが次のコメントをすることで、安定化の受け入れを提案できます。

@rfcbot fcp merge

十分な数のチームメンバーがレビューすると、その PR は「最終コメント期間」（FCP）に移行します。 新たな懸念が提起されなければ、この期間は完了し、その PR は通常どおり実装レビューを経てマージできます。

安定化のレビューとマージ

安定化において、r+ を与える前に、その PR が次を満たしていることを確認してください。

  • チームが安定化対象として提案した内容、および Reference PR に文書化されている内容と一致していること。
  • 懸念を解決または回避するために、チームが途中で要求すると決定した変更をすべて含んでいること。
  • それ以外の点では、安定化レポート、および関連する RFC や過去の lang FCP に記載されている内容と完全に一致していること。
  • 指定され、安定化が受け入れられ、Reference に文書化されたもの以外の挙動を stable で公開していないこと。
  • これらを説得力をもって示すための十分なテストがあること。
  • lang-docs のメンバーによってレビューおよび承認された Reference への PR が添えられていること。

特に、PR をレビューするときは、lang チームが検討および指定し損ねたユーザーから見える詳細がないか注意してください。 そのようなものを見つけた場合は、それを説明し、lang チームに対して PR をノミネートしてください。