# Solidity Language Server

> Documentation and benchmarks for solidity-language-server

## Docs

- [Changelog](/changelog): File operation behaviors are configurable via:
- [Emacs (lsp-mode)](/setup/emacs): Example `lsp-register-client` with full settings:
- [Helix](/setup/helix): Use `languages.toml`.
- [Editor Setup](/setup): All editor configs support the same server settings.
- [Neovim](/setup/neovim): Example from your real setup in `~/.config/nvim/lsp`.
- [Sublime Text (LSP)](/setup/sublime): Add to `LSP.sublime-settings`:
- [Vim](/setup/vim): Credit: [https://github.com/leekt/vimsettings/blob/a0166c68dec7f67c391993a9bbf90668577fb929/.vimrc#L108-L137](https://github.com/leekt/vimsettings/blob/a0166c68dec7f67c391993a9bbf90668577fb929/.vimrc#L108-L137)
- [VS Code](/setup/vscode): Add to `settings.json`:
- [Zed](/setup/zed): Configure LSP settings in Zed:
- [Completions](/reference/completions): This page explains the current completion implementation:
- [Go-to-Definition](/reference/goto): **`CachedBuild`**: a group of Rust `HashMap`s created from a successful build on disk. The maps store things like `node id -> node info` and `source id -> file path`. It is a snapshot, not the live editor buffer.
- [Hover](/reference/hover): This page describes the current `textDocument/hover` implementation:
- [Imports and Navigation](/reference/imports-references): This page is intentionally short and exists to prevent confusion between three related features:
- [Inlay Hints](/reference/inlay-hints): This page documents the current inlay-hint implementation:
- [Memory Profiling with DHAT](/reference/profiling): This page documents how to profile heap usage for the current Rust server implementation.\
Use it when you need to answer:
- [References](/reference/references): This page documents how `textDocument/references` works in the current implementation:
- [Signature Help](/reference/signature-help): **`text_cache`**: in-memory `HashMap<uri, (version, text)>` with current editor text.
- [Symbols](/reference/symbols): The server exposes two symbol methods:
- [File Rename Imports (](/reference/will-rename-files): When a Solidity file is renamed or moved, the server returns import-path edits so dependent files stay valid.
- [Reference](/reference): These pages are implementation-deep technical notes for `solidity-language-server`.
- [Docs Development](/docs/contributing): This docs site uses **Bun** as the package manager.
- [Quickstart](/docs/quickstart): [Editor Setup](/setup)
- [I Benchmarked 3 Solidity LSP Servers. Here's What I Found](/blog/article1): If you write Solidity, your editor's language server is doing more work than you think. Every time you open a file, jump to a definition, or hover over a symbol, your LSP server is racing to give you an answer. The question is: how fast?
I benchmarked three Solidity LSP servers head-to-head against a real-world codebase — Uniswap V4-core's Pool.sol, 618 lines of production Solidity. No toy examples. No hello-world contracts. Just a file that every serious Solidity developer has encountered.
The three servers:
- [v0.1.25: 140 MB Reclaimed, 4x Faster Hover, and Still the Only Server That Passes Everything](/blog/article3): The last article covered v0.1.17 -- 6 servers, 13 methods, one winner. Since then, eight releases have shipped. v0.1.25 is a different server than the one I wrote about two months ago. The feature set has doubled, the internals have been rewritten, and I've spent the last few releases doing something most people skip: making it use less memory, not more.
- [v0.1.26: File Operations You Can Trust, Cleaner Auto-Import, and Better Bench Coverage](/blog/article4): v0.1.26 is a workflow release.
- [Blog](/blog): [v0.1.26 Release Post](/blog/v0-1-26-release)
- [v0.1.26](/blog/v0-1-26-release): This release focuses on file lifecycle correctness and import reliability in real Solidity workflows.
- [Benchmark Overview](/benchmarks/overview): All benchmark content below is rendered from markdown in this repository.