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

新しい言語機能の実装

コンパイラに新しい重要な機能を実装したい場合は、 すべてが円滑に進むように、このプロセスを通る必要があります。

注: このセクションは言語機能を対象としており、別のプロセスを使用するライブラリ機能は対象外です。

言語への変更を提案する方法については、Rust Language Design Team の手順も参照してください。

@rfcbot FCP プロセス

変更が小さく、議論の余地がなく、破壊的変更ではなく、 stable の言語に対してユーザーが観測できる形で影響せず、新しい不安定機能も追加しない場合は、 単に PR を書き、そのコード部分に詳しい人から r+ を得るだけで実施できます。 しかし、そうでない場合は、さらに行うべきことがあります。 コンパイラ内部の作業であっても、 チームの他のメンバーから合意を得ずに議論のある変更を押し通すのはよくありません （「分散システム」という意味では、自分の知らないものを壊さないようにするためであり、 社会的な意味では、PR 上の争いを避けるためです）。

チームの合意が必要な変更については、 最終コメント期間（FCP）を提案するプロセスを使用します。 関連するチームに所属していない場合（したがって @rfcbot の権限がない場合）は、 所属している人に開始を依頼してください。 その人自身に懸念がない限り、開始してくれるはずです。

FCP プロセスが必要なのは、合意が必要な場合だけです – 変更に対して合意を要求するプロセスがなく、 誰も問題にしないと思うなら、r+ だけに頼っても問題ありません。 たとえば、 コンパイラ開発や標準ライブラリでの使用のために、 予約済みのコンパイラ内部用 rustc_ 名前空間にある不安定なコマンドラインフラグや 属性を追加または変更することは、 nightly エコシステムで広く使われることが想定されない限り、FCP なしで問題ありません。 一部のチームは、このようなシナリオで使用する、より軽量なプロセスを持っています。 たとえば、 コンパイラチームは、完全な合意を必要とせずに支持とフィードバックを得る軽量な方法として、 Major Change Proposal（MCP）を提出することを推奨しています。

FCP を提案するために、実装が r+ を得られるほど完全に準備できている必要はありませんが、 少なくとも概念実証があるのは、一般的によい考えです。 そうすることで、人々があなたの話している内容を確認できます。

FCP が提案されると、チームの全メンバーがその FCP を承認する必要があります。 全員が承認した後、 10 日間の「最終コメント期間」（名前の由来です）があり、その間は誰でもコメントできます。 懸念が提起されなければ、その PR/issue は FCP の承認を得ます。

機能を書く際の実務

機能を動作する形で実装するために、 いくつかの「実務上の」手続きを通る必要があるかもしれません。

警告サイクル

場合によっては、機能やバグ修正が、いくつかのエッジケースで既存のプログラムを壊す可能性があります。 その場合は、 影響を評価するために crater run を実施し、必要に応じて将来互換性 lint を追加することになるでしょう。 これは、エディションで制限された lint で使われるものと似ています。

安定性

私たちは Rust の安定性を重視しています。 stable で動作し実行できるコードは、（ほとんどの場合）壊れるべきではありません。 そのため、 チームの合意とコードレビューだけで機能を世に出したくはありません - nightly でその機能を使用する実際の経験を得たいと考えていますし、 その経験に基づいて機能を変更したい場合もあります。

それを可能にするために、 ユーザーが誤ってその新機能に依存しないようにする必要があります - そうしなければ、 特に実験に時間がかかったり遅延したりして、その機能がリリース列車に乗って stable に到達した場合、 事実上 stable になってしまい、 人々のコードを壊さずに変更できなくなってしまいます。

そのための方法として、すべての新機能がフィーチャーゲートされていることを保証します - フィーチャーゲート（#[feature(foo)]）を有効にしなければ使用できず、 これは stable/beta コンパイラでは行えません。 技術的な詳細については、コードにおける安定性セクションを参照してください。

最終的に、その機能を使用して十分な経験を得て、必要な変更を行い、 満足できる状態になったら、こちらで説明されている安定化プロセスを使用して世に公開します。 それまでは、その機能は確定したものではありません。 機能のあらゆる部分は変更される可能性があり、機能が完全に書き直されたり削除されたりする可能性もあります。 機能は、不安定なまま長期間変更されなかったというだけで、既得権を得ることはありません。

追跡 issue

不安定機能の状態、 nightly で使用する中で得られた経験、 そして安定化を妨げている懸念を追跡するために、 すべてのフィーチャーゲートには追跡 issue が必要です。 その機能に関連する issue や PR を作成するときは、この追跡 issue を参照し、 機能の進捗に関する更新があるときは、それらを追跡 issue に投稿してください。

承認済み RFC または承認済みの lang experiment の一部である機能については、 その追跡 issue を使用してください。

その他の機能については、その機能の追跡 issue を作成してください。 issue のタイトルは “Tracking issue for YOUR FEATURE” にする必要があります。 “Tracking Issue” issue テンプレートを使用してください。

Lang experiment

コンパイラに取り込まれるためには、 言語に対してユーザーから見える影響を持つ機能（不安定なものを含む）は、 承認済み RFC の一部であるか、承認済みの lang experiment でなければなりません。

新しい lang experiment を提案するには、 動機と意図した解決策を説明する issue を rust-lang/rust に開いてください。 受け入れられた場合、この issue はその実験の追跡 issue になるため、 これらの他の詳細も含めつつ、追跡 issue のテンプレートを使用してください。 その issue を lang チームに nominate し、@rust-lang/lang と @rust-lang/lang-advisors を CC してください。 実験が承認されると、追跡 issue は B-experimental としてマークされます。

lang experiment に関連するフィーチャーフラグは、 その機能の RFC が承認されるまで incomplete としてマークされなければなりません。

コードにおける安定性

新しい不安定機能を実装するためには、以下の手順に従う必要があります。

  1. トラッキングイシューを開くか、特定します。 受理済み RFC または承認済みの lang experiment の一部であるフィーチャーについては、 そのトラッキングイシューを使用します。

    トラッキングイシューに C-tracking-issue と関連する F-feature_name ラベルを付けます （必要であればそのラベルを追加します）。

  2. フィーチャーゲートの名前を選びます（RFC の場合は、RFC 内の名前を使用します）。

  3. rustc_span/src/symbol.rs の Symbols {...} ブロックにフィーチャー名を追加します。

    このブロックはアルファベット順でなければならないことに注意してください。

  4. rustc_feature/src/unstable.rs の unstable な declare_features ブロックにフィーチャーゲート宣言を追加します。

    /// フィーチャーの説明
(unstable, $feature_name, "CURRENT_RUSTC_VERSION", Some($tracking_issue_number))

    まだトラッキングイシューを開いていない場合 （たとえば、そのフィーチャーが受け入れられそうかどうかについて最初のフィードバックを得たい場合）は、 一時的に None を使用できます。ただし、PR がマージされる前に必ず更新してください！

    例:

    /// ASCII を超える識別子の定義を許可します。
(unstable, non_ascii_idents, "CURRENT_RUSTC_VERSION", Some(55467)),

    フィーチャーは incomplete としてマークできます。 その type を incomplete に設定することで、 デフォルトで警告となる incomplete_features lint を発生させます。

    /// deref パターンを許可します。
(incomplete, deref_patterns, "CURRENT_RUSTC_VERSION", Some(87121)),

    lang experiment に関連するフィーチャーフラグは、 そのフィーチャーの RFC が受理されるまで incomplete としてマークしなければなりません。

    セマンティックなマージコンフリクトを避けるため、 1.70 や別の明示的なバージョン番号ではなく CURRENT_RUSTC_VERSION を使用します。

  5. フィーチャーゲートが設定されていない限り、新しいフィーチャーを使用できないようにします。 コンパイラ内のほとんどの場所では、 式 tcx.features().$feature_name() を使用して確認できます。

    フィーチャーゲートが設定されていない場合は、 状況に応じて、フィーチャー導入前の挙動を維持するか、エラーを発生させるべきです。 エラーには通常 rustc_session::errors::feature_err を使用するべきです。 エラーを追加する例については、#81015 を参照してください。

    新しい構文を導入するフィーチャーでは、代わりに展開前ゲーティングを使用するべきです。 パース中に新しい構文がパースされたとき、 self.psess.gated_spans.gate(sym::my_feature, span) によって、 その symbol を現在のクレートの GatedSpans に挿入しなければなりません。

    gated spans に挿入した後、 実際にフィーチャーを拒否する rustc_ast_passes::feature_gate::check_crate 関数で その span をチェックしなければなりません。 正確にどのようにゲートするかはフィーチャーの正確な種類によりますが、 ほとんどの場合は gate_all!() マクロを使用することになるでしょう。

  6. フィーチャーゲートなしではそのフィーチャーを使用できないことを保証するテストを、 tests/ui/feature-gates/feature-gate-$feature_name.rs を作成して追加します。 対応する .stderr ファイルは、 ./x test tests/ui/feature-gates/ --bless を実行して生成できます。

  7. unstable book にセクションを追加します。 場所は src/doc/unstable-book/src/language-features/$feature_name.md です。

  8. 新しいフィーチャーについて多くのテストを書きます。できれば tests/ui/$feature_name/ に置きます。 テストのない PR は受け入れられません！

  9. PR のレビューを受け、マージします。 これで Rust にフィーチャーを実装することに成功しました！

テストの呼びかけ

実装が完了すると、 そのフィーチャーは nightly ユーザーが利用できるようになりますが、まだ stable Rust の一部ではありません。 これは、Rust のメインブログにブログ記事を書き、 「テストの呼びかけ」を行うのに適したタイミングです。

過去のそのようなブログ記事には次のものがあります。

  1. GAT 安定化に向けた取り組み
  2. Rust 2024 における impl Trait の変更
  3. Async Closures MVP: テストの呼びかけ！

あるいは、This Week in Rust にはこのためのセクションがあります。 これが使用された例の 1 つは次のとおりです。

どの選択肢を選ぶかは、その言語変更がどれほど重要かに依存するかもしれません。 ただし、This Week in Rust のセクションは、 Rust のメインブログでの専用投稿よりも目立ちにくい可能性があることに注意してください。

仕上げ

ユーザーに洗練された体験を提供するということは、単に rustc にフィーチャーを実装する以上のことを意味します。 私たちは、提供しているすべてのツールとリソースについて考える必要があります。 この作業には次が含まれます。

  • 言語フィーチャーを Rust Reference に文書化する。
  • 新しい構文がある場合は、それをフォーマットするように rustfmt を拡張する（該当する場合）。
  • rust-analyzer を拡張する（該当する場合）。 この作業の範囲は言語フィーチャーの性質によって異なる場合があります。 一部のフィーチャーは、完全な サポートを待つ必要がないためです。
    • 言語フィーチャーが rust-analyzer でサポートが実装される前に存在するだけで ユーザー体験を悪化させる場合、 lang チームがブロッキングな懸念を提起する可能性があります。
    • そのような例には、rust-analyzer がパースできない新しい構文や、 誤った診断につながる、rust-analyzer が理解できない型推論の変更などが含まれるかもしれません。

安定化

フィーチャーライフサイクルの最終ステップは安定化です。 これは、そのフィーチャーがすべての Rust ユーザーに利用可能になるときです。 この時点では、 後方互換性のない変更は一般的に許可されなくなります （詳細については、lang チームの定義済み semver ポリシーを参照してください）。 安定化についてさらに詳しく知るには、安定化ガイドを参照してください。