Epic: Language Server Protocol Support #1558
Comments
|
To devs reading: your contributions are most welcome! Feel free to drop a comment on any of the tasks listed if you'd like to one on 🧑💻 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Noir Language Server Protocol
High-level overview of goals and components
Goals
The LSP should be developed in a way that allows us to execute it as a child process when called from a local editor, but we should also be able to instantiate it in the browser to support a Noir editing experience without any server communication. This will likely require a “core” component that is free from the native code that can be consumed by native and wasm-targeting code.
The toolchain that is used in the terminal should be the same as the one available to the LSP clients. We want to avoid situations where a user has Nargo v0.5.2 installed, but the latest extension is providing them with v0.6.0. To solve this, we can add a command to Nargo, such as
nargo lsp, which starts a long-running LSP server. The extension will find nargo in the path and run this command for the user. Providing the LSP command in our nargo tooling also provides a nicer experience for editing experiences where the user must start the LSP process themselves.LSP servers process client messages asynchronously. A client may send messages out-of-order or may try to cancel a request that is in progress. Ensuring the LSP server is asynchronous ensures we can handle all the message types.
The LSP should not write files if at all possible. Since it is a long-running process, it can store files in memory. If it absolutely needs to write files, it should write to a location isolated for just the LSP to avoid file locks—like we’ve all seen with rust-analyzer.
Components
LSP “clients” are the frontends, such as a VSCode extension, that request information from the LSP. They send messages that conform to the language server protocol and expect responses in the same format. The VSCode team provides a helper library that provides most of this functionality for us, so the first “client” will be implemented inside https://github.com/noir-lang/vscode-noir.
LSP “servers” are the backends that respond to the various messages that the client sends. This usually requires processing files and responding with the message in the format the language server protocol specifies. These servers should be long-lived processes that maintain a cache of data in memory. Upon startup, the server provides the client with a set of features it supports (error messages, inlay hints, goto definition, etc), known as capabilities, so the client knows which types of messages it is allowed to send.
Research
Tower
Framework for building “clients” and “servers”
Request->Response based
Bad for stream-based processing
Tower-LSP
Builds on top of Tower
Lots of real-world use
Big problem with tower-lsp not working with cancelRequest: Consider ditching concurrent handler execution ebkalderon/tower-lsp#284
Full demo of tower-lsp in browser: https://github.com/silvanshade/tower-lsp-web-demo
async-lsp
Builds on top of Tower
Less mature (“proof-of-concept”)
Written by nil author (nix LSP) so has some active real-world use
Heavily inspired by tower-lsp but solves problems with it, such as Consider ditching concurrent handler execution ebkalderon/tower-lsp#284
No demo of it working in the browser, but hopefully similar to tower-lsp
lsp-server
low-level, written for & used by rust-analyzer
lsp-types
Rust types that map to LSP protocol messages
lsp-document or lsp-positions
Deal with utf-16 vs utf-8 differences between protocol and Rust
lsp-positions is written by github
noir-lsp
Proof-of-concept LSP for noir written by student
Contains “client” and “server” (duplicated content with our vscode extension)
Tasks
lspcommand to start server that reports no capabilities #1560use dep::stdas an error #1833The text was updated successfully, but these errors were encountered: