LSP

Active contributors: osiewicz, smitbarmase, SomeoneToIgnore, Veykril

Purpose

crates/lsp is Zed's LSP client. It speaks JSON-RPC over stdio with language-server processes, framing requests and notifications according to the LSP spec. The editor and project use this client to surface completions, diagnostics, hovers, code actions, signature help, semantic tokens, inlay hints, formatting, and the rest of the LSP feature surface.

Crates

Crate	Role
crates/lsp	LSP transport, request types, server lifecycle
crates/language	Per-language LspAdapter definitions
crates/project (lsp_store)	Per-project orchestration: which servers run, when, where
crates/editor/src/lsp/	Editor-side surfacing of LSP capabilities
crates/language_tools	In-app LSP log viewer + request inspector
crates/prettier	Prettier-as-LSP integration for formatting
crates/json_schema_store	JSON schema fetching that drives JSON LSP behaviour

Key abstractions

Type	File	Description
LanguageServer	crates/lsp/src/lsp.rs	Spawned process + JSON-RPC framing
LanguageServerId	crates/lsp/src/lsp.rs	Identifier within a project
LspAdapter	crates/language/src/lsp_adapter.rs	Per-language wrapper (install + initialize + path mapping)
LspStore	crates/project/src/lsp_store.rs	Owns the set of running servers per project
Request / notification types	crates/lsp/src/request.rs etc.	Strongly-typed LSP messages

How it works

sequenceDiagram
    participant E as Editor
    participant P as Project
    participant LS as LspStore
    participant L as LanguageServer
    participant RA as rust-analyzer (proc)

    E->>P: open buffer foo.rs
    P->>LS: ensure_server_for(language=rust)
    LS->>L: spawn(rust-analyzer)
    L->>RA: stdio JSON-RPC
    L-->>LS: initialize result
    E->>L: textDocument/completion
    L->>RA: request
    RA-->>L: response
    L-->>E: completions

Server lifecycle

• The first time a buffer of language X is opened, LspStore consults the language's LspAdapter and spawns a server. Subsequent buffers of the same language reuse it.
• Adapters install missing binaries on demand. Many use the project Node runtime (crates/node_runtime) to fetch npm-distributed servers.
• Servers receive initialize with the project root and workspaceFolders, then sync open buffers via textDocument/didOpen.
• On project close, all servers are terminated cleanly.

Editor capabilities

crates/editor/src/lsp/ surfaces:

• Completion (textDocument/completion).
• Hover (textDocument/hover).
• Signature help.
• Code actions (quick-fixes, refactors).
• Diagnostics (push-published by the server).
• Document symbols and outlines (via crates/outline).
• Definitions, references, implementations, type definitions.
• Inlay hints.
• Formatting and range formatting.
• Rename.
• Semantic tokens (highlighting refinement on top of tree-sitter).

Tracing and debugging

crates/language_tools exposes an in-app viewer for LSP traffic. Open it via the command palette:

• dev: open language server logs — stderr from servers.
• dev: open language server stats — per-server timing.
• The request inspector lets you replay individual requests for debugging.

Integration points

• Inputs: Per-language LspAdapter registrations from crates/languages and from extensions.
• Outputs: Diagnostics back into Buffers; completions, hovers, inlay hints into Editor.
• Cross: crates/extension_host lets extensions register adapters too.

Entry points for modification

• Adding a new built-in adapter — crates/languages/src/<language>.rs plus registration.
• Improving transport — crates/lsp/src/lsp.rs.
• Surfacing a new LSP capability — extend the editor UI in crates/editor/src/lsp/ plus the request type if missing.
• Tracing — crates/language_tools/src/.

Related pages

• Language services — where adapters are registered
• Editor — where LSP results are surfaced
• Extensions — third-party adapters