Protocole du serveur de langue

Le protocole Language Server Protocol ( LSP ) est un protocole ouvert basé sur JSON-RPC destiné à être utilisé entre les éditeurs de code source ou les environnements de développement intégrés (IDE) et les serveurs qui fournissent des « outils d'intelligence linguistique » : des fonctionnalités spécifiques au langage de programmation telles que la saisie semi-automatique du code , la mise en évidence de la syntaxe et le marquage des avertissements et des erreurs, ainsi que des routines de refactorisation . L'objectif du protocole est de permettre la mise en œuvre et la distribution du support du langage de programmation indépendamment de tout éditeur ou IDE donné. Au début des années 2020, LSP est rapidement devenu une « norme » pour les fournisseurs d'outils d'intelligence linguistique.

LSP a été développé à l'origine pour Microsoft Visual Studio Code et est désormais un standard ouvert. Le 27 juin 2016, Microsoft a annoncé une collaboration avec Red Hat et Codenvy pour normaliser la spécification du protocole. Le protocole était initialement pris en charge et adopté par ces trois sociétés. Sa spécification est hébergée et développée sur GitHub .

Les IDE modernes offrent aux programmeurs des fonctionnalités sophistiquées telles que la saisie semi-automatique du code , la refactorisation , la navigation vers la définition d'un symbole , la mise en évidence de la syntaxe et les marqueurs d'erreur et d'avertissement.

Par exemple, dans un langage de programmation textuel, un programmeur peut vouloir renommer une méthode read. Le programmeur peut soit modifier manuellement les fichiers de code source respectifs et remplacer les occurrences appropriées de l'ancien nom de méthode par le nouveau nom, soit utiliser les capacités de refactorisation d'un IDE pour effectuer automatiquement toutes les modifications nécessaires. Pour pouvoir prendre en charge ce style de refactorisation, un IDE doit avoir une compréhension sophistiquée du langage de programmation dans lequel la source du programme est écrite. Un outil de programmation sans une telle compréhension (par exemple, un outil qui effectue une recherche et un remplacement naïfs à la place) pourrait introduire des erreurs. Lors du renommage d'une readméthode, par exemple, l'outil ne doit pas remplacer la correspondance partielle dans une variable qui pourrait être appelée readyState, ni la partie d'un commentaire de code contenant le mot "déjà". Le renommage d'une variable locale , par exemple, ne doit pas non plus readfinir par modifier des variables portant le même nom dans d'autres portées .

Les compilateurs ou interprètes conventionnels pour un langage de programmation spécifique ne sont généralement pas en mesure de fournir ces services de langage , car ils sont écrits dans le but de transformer le code source en code objet ou d'exécuter immédiatement le code. De plus, les services de langage doivent être capables de gérer le code source qui n'est pas bien formé , par exemple parce que le programmeur est en train de l'éditer et n'a pas encore fini de taper une instruction, une procédure ou une autre construction. De plus, les petites modifications apportées à un fichier de code source pendant la saisie modifient généralement la sémantique du programme. Afin de fournir un retour instantané à l'utilisateur, l'outil d'édition doit être capable d'évaluer très rapidement les conséquences syntaxiques et sémantiques d'une modification spécifique. Les compilateurs et les interprètes constituent donc un mauvais candidat pour produire les informations nécessaires à la consommation d'un outil d'édition.

Avant la conception et la mise en œuvre du protocole Language Server pour le développement de Visual Studio Code, la plupart des services de langage étaient généralement liés à un IDE donné ou à un autre éditeur. En l'absence du protocole Language Server, les services de langage sont généralement mis en œuvre à l'aide d'une API d'extension spécifique à l'outil. Fournir le même service de langage à un autre outil d'édition nécessite des efforts pour adapter le code existant afin que le service puisse cibler les interfaces d'extension du deuxième éditeur.

Le protocole de serveur de langage permet de découpler les services de langage de l'éditeur afin que les services puissent être contenus dans un serveur de langage à usage général . Tout éditeur peut hériter d'un support sophistiqué pour de nombreux langages différents en utilisant des serveurs de langage existants. De même, un programmeur impliqué dans le développement d'un nouveau langage de programmation peut mettre des services pour ce langage à la disposition des outils d'édition existants. L'utilisation de serveurs de langage via le protocole de serveur de langage réduit ainsi également la charge pesant sur les fournisseurs d'outils d'édition, car les fournisseurs n'ont pas besoin de développer leurs propres services de langage pour les langages que le fournisseur a l'intention de prendre en charge, tant que les serveurs de langage ont déjà été implémentés. Le protocole de serveur de langage permet également la distribution et le développement de serveurs fournis par un tiers intéressé, tel que des utilisateurs finaux, sans implication supplémentaire du fournisseur du compilateur pour le langage de programmation utilisé ou du fournisseur de l'éditeur auquel le support de langage est ajouté.

LSP ne se limite pas aux langages de programmation. Il peut être utilisé pour tout type de langage textuel, comme les spécifications ou les langages spécifiques à un domaine (DSL) .

Lorsqu'un utilisateur modifie un ou plusieurs fichiers de code source à l'aide d'un outil compatible avec le protocole de serveur de langage, l'outil agit comme un client qui consomme les services de langage fournis par un serveur de langage . L'outil peut être un éditeur de texte ou un IDE et les services de langage peuvent être la refactorisation , la saisie semi-automatique de code , etc.

Le client informe le serveur de ce que fait l'utilisateur, par exemple ouvrir un fichier ou insérer un caractère à un emplacement de texte spécifique. Le client peut également demander au serveur d'exécuter un service linguistique, par exemple formater une plage spécifiée dans le document texte. Le serveur répond à la demande du client par une réponse appropriée. Par exemple, la demande de formatage reçoit une réponse qui transfère le texte formaté au client ou une réponse d'erreur contenant des détails sur l'erreur.

Le protocole Language Server Protocol définit les messages à échanger entre le client et le serveur de langue. Il s'agit de messages JSON-RPC précédés d'en-têtes similaires à HTTP. Les messages peuvent provenir du serveur ou du client.

Le protocole ne prévoit aucune disposition sur la manière dont les requêtes, les réponses et les notifications sont transférées entre le client et le serveur. Par exemple, le client et le serveur peuvent être des composants au sein du même processus échangeant des chaînes JSON via des appels de méthode. Il peut également s'agir de processus différents sur la même machine ou sur des machines différentes communiquant via des sockets réseau .

Il existe des listes d'implémentations compatibles LSP, maintenues par le site communautaire Langserver.org ou par Microsoft.