View source for Language Server for Visual Studio

Encadrants: Olivier Gruber

Elèves 5A: 



Microsoft Visual Studio is not only a great development tool for existing programming languages, it is also extensible to support new languages. To achieve this, Microsoft has profoundly changed the split of responsibilities between our different development tools: the editor, the compiler, and the debugger.

Traditionally, the compiler is a standalone program reading source files and producing object files and executable files. The debugger is also a standalone program, usually with a poor user interface, like the command-line version of GNU gdb for instance. Then comes the editor that was originally concerned with syntax highlighting and editing. Of course, we all know about Integrated Development Environments (IDEs), such as Eclipse that combine all those tools needed, but in a monolithic design.

The revolutionary idea of Microsoft is to divide the responsibilities differently, separating the language-specific support from the generic editing support. VisualStudio has no built-in knowledge about the programming languages in support, it entirely relies on language servers for the specific knowledge that is necessary for syntax-highlighting, language-aware navigation, or advanced debugging. The novel approach relies around two protocols:

*  The Language Server Protocol:  "A Language Server is meant to provide the language-specific smarts and communicate with development tools over a protocol that enables inter-process communication."
* The Debug Adapter Protocol : "The idea behind the Debug Adapter Protocol (DAP) is to abstract the way how the debugging support of development tools communicates with debuggers or runtimes into a protocol."

Of course, Microsoft Visual Studio has the support for these protocols with a classical client-server architecture where the client is VisualStudio and the server is the language server, with the two protocols relying on the JSON RPC standard for communication.

The goal of this exploratory project is to evaluate how hard can it be to provide both protocols for a new language with a language server written in Java. In doing so, we are faced with two challenges:

* Implement the communication layer for JSON RPC over NIO sockets.
* Implement the language server itself, interacting with VisualStudio, through the JSON RPC layer.

The focus of this project is the first, that is, the implementation of the communication layer for JSON RPC over NIO. The JSON RPC 2.0 specification is a simple string-oriented protocol, similar to HTTP. Our first goal is to have an NIO-based implementation, from scratch, using only our own classes; an implementation suited to build a small reactive event-oriented language server.

For the language server itself, we only want a small prototype that allows to understand how the two protocols (LSP & DAP) work for syntax highlighting, navigation, and debugging. We therefore need a simple language that we can parse and execute. Thankfully, we have one, the one we developed in Info3-POO in the sprint "object.calculator". We have a parser, an AST, and an evaluator, everything we need to build a language server and a debug adapter, based on your own code that you already know.

This project will require to be curious and resourceful, as this is an exploratory project. And yet, although exploratory, this project is not intended to be a throw-away project. The intent is to be able to use VisualStudio as an IDE for a simplified version of the Java language, called Bali, suited for teaching and for embedded system development. One hope is that it could be used in Info3 Object-Oriented Programming course to help beginners.

To ensure success and reduce the learning curve, developers for this project must be regular VisualStudio users and it would be better if they have some experience with writing VisualStudio plugins.