LSP と Language Server

IDE の補完、ジャンプ、ホバー時の型表示、リファクタリング——これらのコードインテリジェンスはすべて Language Server から提供されます。Language Server は本質的に「コンパイラフロントエンド＋増分更新＋エラー許容パーサ」です。LSP は、字句・構文・シンボルテーブルの機能を JSON-RPC としてエディタに公開します。

概要

IDE のコードインテリジェンス——補完、定義へのジャンプ、ホバー時の型表示、リファクタリング——は、従来、各 IDE が各言語ごとに独自の解析ロジック（M × N）を実装していました。LSP（Language Server Protocol）は、MCP と同じ戦略を用いてこの問題を解決します。⁠各言語に対して 1 つの Language Server プロセスを提供し、IDE は JSON-RPC を介してそれと通信するのです。コンパイラ技術の観点から見ると、LSP はコンパイラフロントエンド（字句・構文・意味解析・シンボルテーブル）の直接的な消費者であり、Language Server は本質的に「コンパイラフロントエンド＋増分更新エンジン」です。ここでは、LSP プロトコルのコアなリクエストタイプ、Language Server が内部で前述のコンパイラフロントエンド技術を用いてインデックス構築と応答をどのように行っているか、そしてなぜ「十分に速いこと」が「十分に正確なこと」よりも難しいのかについて解説します。

LSP はコンパイラではない：コンパイラフロントエンドの目標を少し変えたもの

コンパイラが求めるもの：ソースコードから機械語を生成し、正しさが最優先。一連のファイルに対してバッチ処理を行う。 Language Server が求めるもの：ユーザーが1文字入力するたびに <100ms 以内に補完・診断・ハイライトを更新し、⁠不完全なコードやエラーのあるコードに対しても合理的な結果を出力し、変更された部分のみを再計算する。

後者の要件により、Language Server はコンパイラパイプライン全体をそのまま実行することはできません。⁠増分的である必要があり、かつ構文エラーを許容する必要があります（ユーザーが途中までコードを書いている時点で、ソースコードには必ず構文エラーが含まれるため）。

コアなリクエストタイプ：すべてシンボルテーブルと AST の問い合わせ

LSP のすべてのリクエストは、コンパイラフロントエンドのデータ構造に対する問い合わせです。

すべての機能は シンボルテーブル に由来します。 definition はシンボルテーブルの1回のルックアップ、references はシンボルの使用リスト、completion は現在のスコープにおけるシンボルテーブルの列挙、hover はシンボルの型とドキュメント文字列です。もしシンボルテーブルが「この名前がどこで参照されているか」という逆引きインデックスを保持していなければ、references や rename を効率的に行うことはできません。そのため、シンボルテーブルの構築時には双方向の（定義から参照へ、参照から定義へ）インデックスが必要です。

インデックス：ファイルを開く前に、各ファイルが何をエクスポートしているかを知る

大規模プロジェクトでは数千ものファイルが存在し、ユーザーが main.rs を開いた時点で、Language Server がプロジェクト全体を解析している余裕はありません。そのため、⁠永続化されたインデックスが必要です。

rust-analyzer は salsa（増分計算フレームワーク）を用いてこのインデックスを管理しており、変更が生じた場合でも影響を受けるファイルのみを再計算し、影響を受けないファイルはキャッシュから直接取得します。これが IDE の応答を <100ms に保つ鍵です——全量再計算ではなく、増分更新を行っているためです。

エラー許容パーサ：構文エラーのある入力に対して結果を出力する

ユーザーが入力している間（let x = some_struct. など）、ソースコードは必然的に不完全です。パーサは some_struct. の後のドットを見て、フィールド名を期待しますが EOF（ファイル終端）に遭遇します。コンパイラであれば、ここでエラーを出力して処理を停止します。しかし Language Server は停止できず、エラーから回復して . の後に続く可能性のあるフィールドの補完を出力しなければなりません⁠。

これには、AST 設計とエラー回復 で述べたエラー回復機構が重要です。不完全な式が見つかっても、パーサはその式の AST ノード（エラーとしてマーク済み）を構築し続け、上位の意味解析はこの「エラーを含む AST」に対して部分的な型推論を行います。some_struct の型情報からフィールドリストを取得し、補完候補として返します。

ユーザー入力: let x = some_struct.
パーサ出力: Expr::Field { object: "some_struct", field: <Error> }
意味解析: シンボルテーブルから some_struct の型を参照 → StructFoo { a: i32, b: String }
補完: [a: i32, b: String]

エラー回復がなければ補完は存在しません——これらは Language Server において一対の機能です。区別できるのは「現在のトークンが完全な式である場合」と「現在のトークンが構文エラーである場合」だけであり、後者の場合、パーサが出力する AST ノードに「フィールドが欠落している」ことを示すマークが必要であり、意味解析はこれに基づいてユーザーが補完を期待していることを知ります。

Semantic Tokens: 構文ハイライトの別の実装方法

従来のハイライトは正規表現マッチ（Tree-sitter の highlights.scm）を用いていましたが、正規表現には意味（セマンティクス）の知識がありません。foo は let foo = ... 内では変数定義、foo() 内では関数呼び出し、fn foo() 内では関数宣言です。LSP の textDocument/semanticTokens/full は、⁠各トークンに意味カテゴリ（variable、function、keyword、type、comment...）を割り当て⁠、IDE がそのカテゴリに基づいて着色を行います。

Language Server は AST とシンボルテーブルに基づき、各トークンに意味カテゴリを決定します。これには、レキサが出力するトークンが十分な情報を持っていること（識別子か？シンボルテーブルの逆引きで変数か関数か型か？）か、あるいは意味解析によって追加で注釈が付けられている必要があります。

アーキテクチャ：シングルスレッド、マルチスレッド、増分スケジューリング

産業用の Language Server（rust-analyzer、clangd）の典型的なアーキテクチャは以下の通りです。

デバウンスとキャンセルはパフォーマンスの生命線です。ユーザーが高速に入力している間、on_type の頻度は約 100ms に1文字です。もし文字ごとにファイルの全量解析を行えば、Language Server は確実にフリーズします。デバウンスは「連続する N 回の入力」を「最後の入力の後に解析」にまとめ、キャンセルは時代遅れになった中間結果を破棄します。

参考文献

• LSP 3.17 specification: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/
• rust-analyzer: https://github.com/rust-lang/rust-analyzer — Rust LSP サーバーのアーキテクチャドキュメントとソースコード
• Clangd: https://clangd.llvm.org — Clang フロントエンドに基づく C/C++ 用 LSP サーバー

Keywords: LSP, Language Server Protocol, JSON-RPC, completion, go-to-definition, find-references, hover, diagnostics, semantic tokens, incremental parsing, index, debounce, cancellation, error-tolerant parsing, symbol table reverse lookup, rust-analyzer, clangd