Rust 開発者向けの IDE サポートを改善するために、rust-analyzer と呼ばれる代替コンパイラ フロントエンドの公式採用が提案され、プログラミング言語のコア チームからの支持を得ています。
最近の Rust の調査では、ツールの改善が要望リストの上位にあることが示されており、rust-analyzer は、高速コードナビゲーション、構文の強調表示、コードエディターでの関数の即時実行、コード補完のヒント、およびコードを自動的に記述する「電球」の提案を提供することで、ソリューションの一部となる可能性があります。
rust-analyzer の主要作者は、JetBrains で Rust 用の IntelliJ プラグインの開発に携わり、現在は Ferrous Systems で Rust ソリューションの開発に携わっている Aleksey Kladov 氏です。rust-analyzer の発表において、Kladov 氏はこのプロジェクトが「IntelliJ Rust の開発経験から直接インスピレーションを得た」と述べています。彼は、既存の Rust Language Server (RLS) に代わる Visual Studio Code の公式 LSP (Language Server Protocol) 実装として rust-analyzer を正式に採用することを提案する RFC を提出しました。
RFC では、rust-analyzer へのフィードバックから始まり、第 2 段階として RLS を非推奨にし、最終的に RLS のサポートを停止する移行期間を提案しています。
写真の rust-analzer は IDE サポート用に設計されていますが、rustc コンパイラの進化にも影響を与えます... クリックして拡大
コードエディタやIDEのスマート機能は、裏で多くの処理を行っています。コードの構文が正しいかどうかを確認する最良の方法は、実際にコンパイルしてみることです。一方、ほとんどのコンパイラはIDEのスマート機能の駆動に最適化されていません。クラドフ氏によると、C#の場合、MicrosoftはIDEの充実したサポートを実現するために、コンパイラをRoslynプロジェクトとして書き直しました。KotlinやTypeScriptなどの最近の言語は「最初からIDEを念頭に置いて実装されている」とクラドフ氏は述べ、DartとSwiftのコンパイラもこのニーズを考慮して再度作り直されました。
Rustコンパイラrustcはモノリシックなコードベースを持ち、IDEとの連携ではなくバッチコンパイルに最適化されているとクラドフ氏は述べた。「例えば、コンパイラは現在、すべての型をインターンし、コンパイル終了時にそれらを一度に解放します。これは非常に効率的ですが、長時間実行されるプロセスには必ずしも適していません。時間の経過とともにメモリ使用量が非常に高くなる可能性があるからです。」既存のRLSは、コードをコンパイルして分析データを保存し、それを解析して「エラーの表示や定義へのジャンプ処理」などを行うという仕組みです。これは処理速度が遅く、低レイテンシが求められるコード補完などの機能には適していません。
Rustを信頼しているか？確かにそうだが、より良いツールとより幅広い利用法を望んでいると開発者は言う
続きを読む
Rust-analyzerは、事実上コンパイラを「完全に増分的なオンデマンドスタイル」で再実装することでこの問題を回避しています。これにより、処理速度が向上し、より多くの機能をサポートできるようになりますが、まだ完成しておらず、プロジェクトのステータスはアルファ版です。初期ユーザーはこれを高く評価しており、このプロジェクトはVS Code拡張機能として23,000回ダウンロードされ、5つ星の評価を受けています。「私にとって、rust-analyzerはここしばらく優れた選択肢でした」と、GitHubのあるRust開発者は述べています。
明らかな欠点は、RLSが単純にrustcをベースに構築されているのに対し、rust-analyzerは事実上、rustcと同期を保つ必要がある第2のコンパイラであるということです。Kladov氏は、rustcをライブラリに分割することでモジュール化すべきだと主張しました。これは既に表明されている目標であり、rust-analyzerをrustcと共有するライブラリのための「浅いフロントエンド」として利用できるようにするべきです。つまり、rust-analyzerの公式採用は、ツールサポートの改善だけでなく、コンパイラ技術そのものにも大きな影響を与えるということです。
RFCは十分な支持を得ていますが、特にタイミングに関しては異論もあります。「新参者としてお願いしたいのは、rlsが本当にrlsの代替として使えるようになるまでは、rust-analyzerに切り替えてrlsを廃止しないでほしいということです。今のところ、新しいLSPサーバーの開発はワクワクするものの、まだそこまでには至っていません」と開発者のSeth Bromberger氏は述べています。
MozillaのコアRustチームメンバーであるNiko Matsakis氏は、このRFCを支持し、マージを提案しています。彼は、移行の正確な時期はまだ調整中であり、「rust-analyzerが公式クライアントとして採用される前に、LSPプロトコルに完全に準拠する必要があります。その旨のメモを追加します」と述べています。現在、この分野にはいくつかの欠陥があります。とはいえ、Matsakis氏はRLSとの機能の整合性は「最終目標への進捗を遅らせる可能性がある」ため、必須ではないと主張しました。
Igor Matuszewski 氏からも支持を得ており、同氏は「RLS のメンテナーとして、これを統合することに賛成です」と述べています。
したがって、この RFC は承認される可能性が高いと思われます。®
