ファントムエラーのないプル診断
SharpLsp チーム
Nimblesite エンジニアリング
診断は開発者のフィードバックループです。Problems パネルが嘘をつくなら、人々はそれを信用するのをやめます。SharpLsp の診断アーキテクチャはその制約を中心に構築されています。コンパイラーが知っていることを報告し、ワークスペースが変化するときは積極的に無効化し、半分ロードされたソリューションが完全であるふりをしないでください。
SharpLsp は LSP 3.17 診断モデル を中心に診断を実装しています。エディターは診断レポートをプルし、サーバーはキャッシュされた結果を破棄すべき時にワークスペースリフレッシュ通知を送ります。
なぜロード中のプッシュ診断はリスクがあるのか
大規模な .NET ソリューションは一度にセマンティックに完全にはなりません。ワークスペースはまだ NuGet パッケージを復元中かもしれません。ソースジェネレーターはまだ出力を生成していないかもしれません。プロジェクト参照はまだ解決中かもしれません。Roslyn はファイルをパースするのに十分な状態を持っているかもしれませんが、ソリューションに対する最終的なセマンティックな答えを出すのに十分な状態はないかもしれません。
言語サーバーが早すぎる診断をプッシュすると、ワークスペースのロードが完了すれば正しく解決する型に対して偽の CS0246 または CS0234 エラーがユーザーに表示される可能性があります。エディターは失敗しませんでした。サーバーが早まって主張しすぎたのです。
SharpLsp はこの失敗モードを避けます。
プル + リフレッシュループ
SharpLsp の診断フローは次のとおりです。
- エディターがソリューションまたはドキュメントを開きます。
- Rust LSP ホストがドキュメント状態を追跡し、セマンティックリクエストをサイドカーにルーティングします。
- C# サイドカーは Roslyn ワークスペースの状態を使用してドキュメントまたはワークスペースの診断プルに答えます。
- 各結果は、プロジェクト、ドキュメント、グローバルワークスペースの状態に基づく識別子を持ちます。
- ワークスペースの状態が変化すると、サイドカーはホストに通知します。
- ホストは
workspace/diagnostic/refreshを送信します。 - エディターは新しい状態の下で再びプルします。
これによりエディターはキャッシュ可能なプロトコルを持ち、古い権限はありません。
NuGet 復元ゲート
NuGet の復元は .NET ツールにおけるファントム診断の最大の原因のひとつです。欠落したアセットは完全に有効なコードを壊れているように見せることがあります。SharpLsp の診断仕様は復元状態を利便性ではなく正確性の一部として扱います。
ソリューションの Roslyn ワークスペースを作成する前に、SharpLsp の設計には古い project.assets.json 状態の復元ゲートが含まれています。目的は本物のコンパイラーエラーを隠すことではありません。目的は、パッケージ参照をまだ知ることができないワークスペースに対して診断が計算されるのを防ぐことです。
何をユーザーは期待できるか
SharpLsp はまだアルファソフトウェアです。VS Code 拡張機能が主要な検証の場であり、診断パスはモックのプロジェクトグラフではなく実際の Roslyn の動作を中心に引き締められています。
目標は明確です。SharpLsp が C# 診断を表示するとき、それはワークスペースに対する Roslyn の現在の理解を反映すべきです。Roslyn の理解が変化するとき、SharpLsp はエディターに再度聞き直させるべきです。それが .NET LSP が信頼を得る方法です。