言語サーバープロトコル

言語サーバープロトコル（LSP）は、ソースコードエディターまたは統合開発環境（IDE）と「言語インテリジェンスツール」を提供するサーバーとの間で使用されるオープンなJSON-RPCベースのプロトコルです。 ^[1]コード補完、構文の強調表示、警告やエラーのマーク、リファクタリングルーチンなどのプログラミング言語固有の機能。このプロトコルの目標は、プログラミング言語サポートを、特定のエディターやIDEに依存せずに実装および配布できるようにすることです。^[2] 2020年代初頭、LSPは言語インテリジェンスツールプロバイダーにとって急速に「標準」になりました。^[1]

LSPはもともとMicrosoft Visual Studio Code用に開発され、現在はオープンスタンダードとなっている。2016年6月27日、MicrosoftはRed HatおよびCodenvyと連携してプロトコルの仕様を標準化すると発表。このプロトコルはもともとこの3社によってサポートされ、採用されていた。 ^{[3] [4]その仕様は}GitHubでホストされ、開発されている。^[5]

最新の IDE は、コード補完、リファクタリング、シンボルの定義への移動、構文の強調表示、エラーおよび警告マーカー などの洗練された機能をプログラマーに提供します。

たとえば、テキストベースのプログラミング言語で、プログラマーが メソッド の名前を変更するとしますread。プログラマーは、それぞれのソース コード ファイルを手動で編集して、古いメソッド名を新しい名前に適切に変更するか、IDE のリファクタリング機能を使用して必要な変更をすべて自動的に行うことができます。このスタイルのリファクタリングをサポートするには、IDE がプログラムのソースが記述されているプログラミング言語を高度に理解している必要があります。そのような理解を持たないプログラミング ツール (たとえば、単純な検索と置換を実行するツール) では、エラーが発生する可能性があります。たとえば、メソッドの名前を変更する場合、ツールは と呼ばれる可能性のある変数内の部分一致を置き換えたり、コード コメントの「already」という単語を含む部分を置き換えたりしてはなりません。たとえば、ローカル変数の名前を変更しても、他のスコープ内の同じ名前の変数が変更されることはありません。 readreadyState read

特定のプログラミング言語用の従来のコンパイラやインタープリタは、ソースコードをオブジェクトコードに変換するか、コードをすぐに実行することを目的として書かれているため、通常、これらの言語サービスを提供できません。さらに、言語サービスは、たとえばプログラマが編集の途中で、ステートメント、プロシージャ、またはその他の構造の入力をまだ完了していないために、整形式でないソースコードを処理できなければなりません。さらに、入力中にソースコードファイルに小さな変更を加えると、通常、プログラムの意味が変わります。ユーザーに即時のフィードバックを提供するために、編集ツールは、特定の変更の構文的および意味的な結果を非常に迅速に評価できなければなりません。したがって、コンパイラとインタープリタは、編集ツールが消費するために必要な情報を生成するための候補としては適していません。^[6]

Visual Studio Code の開発のための言語サーバー プロトコルの設計と実装以前は、ほとんどの言語サービスは特定の IDE または他のエディターに結び付けられていました。言語サーバー プロトコルがない場合、言語サービスは通常、ツール固有の拡張 API を使用して実装されます。同じ言語サービスを別の編集ツールに提供するには、サービスが 2 番目のエディターの拡張インターフェイスをターゲットにできるように既存のコードを適応させる作業が必要です。^[7]

言語サーバー プロトコルは、言語サービスをエディターから分離し、サービスを汎用言語サーバー内に収めることを可能にします。既存の言語サーバーを利用することで、どのエディターでもさまざまな言語の高度なサポートを継承できます。同様に、新しいプログラミング言語の開発に携わるプログラマーは、その言語のサービスを既存の編集ツールで利用できるようにすることができます。^[6] 言語サーバー プロトコルを介して言語サーバーを利用すると、言語サーバーがすでに実装されている限り、ベンダーはサポートする予定の言語用に独自の言語サービスを開発する必要がないため、編集ツールのベンダーの負担も軽減されます。言語サーバー プロトコルは、エンド ユーザーなどの関心のある第三者が提供したサーバーの配布と開発も可能にします。その場合、使用中のプログラミング言語のコンパイラのベンダーや、言語サポートが追加されるエディターのベンダーが関与する必要はありません。^[要出典]

^{LSPはプログラミング言語に限定されません。仕様[8]}やドメイン固有言語（DSL）^[9]など、あらゆる種類のテキストベースの言語に使用できます。

ユーザーが言語サーバー プロトコル対応ツールを使用して 1 つ以上のソース コード ファイルを編集する場合、ツールは言語サーバーによって提供される言語サービスを利用するクライアントとして機能します。ツールはテキスト エディターまたはIDEであり、言語サービスはリファクタリング、コード補完など です。

クライアントは、ファイルを開いたり、特定のテキスト位置に文字を挿入したりするなど、ユーザーが行っている操作についてサーバーに通知します。また、クライアントは、テキスト ドキュメント内の指定された範囲をフォーマットするなど、言語サービスを実行するようにサーバーに要求することもできます。サーバーは、クライアントの要求に対して適切な応答を返します。たとえば、フォーマット要求には、フォーマットされたテキストをクライアントに転送する応答、またはエラーの詳細を含むエラー応答のいずれかで応答します。

言語サーバー プロトコルは、クライアントと言語サーバーの間で交換されるメッセージを定義します。これらは、 HTTP に似たヘッダーが先頭に付いたJSON-RPCです。メッセージはサーバーまたはクライアントから発信されます。

このプロトコルでは、クライアントとサーバーの間で要求、応答、通知がどのように転送されるかについては規定されていません。たとえば、クライアントとサーバーは、メソッド呼び出しを介してJSON文字列を交換する同じプロセス内のコンポーネントである可能性があります。また、ネットワーク ソケットを介して通信する同じマシンまたは異なるマシン上の異なるプロセスである可能性もあります。

コミュニティ主導のLangserver.org ^[10]やMicrosoft ^{[11]によって管理されているLSP互換の実装のリストがあります。}

• Gunasinghe, N.; Marcus, N. ( 2021). 言語サーバープロトコルと実装: 言語スマート編集およびプログラミングツールのサポート。Apress。ISBN 978-1-4842-7791-1。

• 公式サイト