Polonius Alpha が Nightly に登場：Rust の借用チェッカーがフローセンシティブに

Rust の借用チェッカーは、NLL が元の AST ベースのチェッカーを置き換えて以来、初のメジャーアップグレードを迎えています。チームは Polonius Alpha を nightly で有効化しました。これは、ライフタイムの生存関係にフローセンシティブな解析をもたらす新しい定式化です。これは2018年に始まった作業の集大成であり、2023年に考案された新しいアプローチは、既存の NLL 実装の最小限の再アーキテクチャで済みました。

Polonius Alpha が解放するもの

NLL との主な違いは、Polonius Alpha がフローセンシティブであることです。つまり、借用が使用されないブランチでは借用が生存していないことを理解します。NLL の解析はフローインセンシティブであり、実際には健全なコードを拒否してしまいます。

典型的な例は、マップから可変参照を返し、キーが存在しない場合はデフォルト値を挿入する関数です：

fn get_mut_or_default<'r, K: Hash + Eq + Copy, V: Default>(
    map: &'r mut HashMap<K, V>,
    key: K,
) -> &'r mut V {
    match map.get_mut(&key) {
        Some(value) => value,
        None => {
            map.insert(key, V::default());
            map.get_mut(&key).unwrap()
        }
    }
}

NLL では、Some(value) => value ブランチにより、借用チェッカーは map.get_mut からの借用が関数全体で生存していると見なします。実際には None ブランチでは生存していないにもかかわらずです。Polonius Alpha はそれを理解しています。

完璧ではないが、近い

Polonius Alpha は、元の（遅い）Polonius 実装のスーパーセットではありません。レガシー Polonius でコンパイルできた一部のプログラムは Alpha ではコンパイルできず、その逆も同様です。チームはこれを認識しており、「Alpha」と呼んでいるのには理由があります。

パフォーマンスが主な懸念事項です。Polonius Alpha は NLL と同等かそれ以上の作業を厳密に行い、チームはリグレッションを監視してきました。ダウンロード数上位1万クレートでは、重大なリグレッションはほとんど見つからず、そのセット外の最悪のケースでは、借用が多いクレートで2〜3倍の遅延が見られます。チームは、追加された機能を考慮するとこれは許容範囲だと考えています。

オプトアウトと今後のステップ

nightly を使用していて NLL を使い続けたい場合は、rustc に -Zpolonius=off を渡すか、RUSTFLAGS=-Zpolonius=off を設定するか、.cargo/config.toml ファイルを使用します：

[target.x86_64-unknown-linux-gnu]
rustflags = ["-Zpolonius=off"]

チームは、安定化前に不健全性、パフォーマンスのリグレッション、診断の問題を発見するために、GitHub と Zulip でフィードバックを求めています。安定化は年内を目標としています。その後、Polonius のアクティブな機能開発は一時停止し、最適化とその他の優先事項に焦点が移ります。