2 lsp_ext.rs hash: 854109e98d02a780
4 If you need to change the above hash to make the test pass, please check if you
5 need to adjust this doc as well and ping this issue:
7 https://github.com/rust-analyzer/rust-analyzer/issues/4604
13 This document describes LSP extensions used by rust-analyzer.
14 It's a best effort document, when in doubt, consult the source (and send a PR with clarification ;-) ).
15 We aim to upstream all non Rust-specific extensions to the protocol, but this is not a top priority.
16 All capabilities are enabled via the `experimental` field of `ClientCapabilities` or `ServerCapabilities`.
17 Requests which we hope to upstream live under `experimental/` namespace.
18 Requests, which are likely to always remain specific to `rust-analyzer` are under `rust-analyzer/` namespace.
20 If you want to be notified about the changes to this document, subscribe to [#4604](https://github.com/rust-analyzer/rust-analyzer/issues/4604).
24 rust-analyzer supports clangd's extension for opting into UTF-8 as the coordinate space for offsets (by default, LSP uses UTF-16 offsets).
26 https://clangd.llvm.org/extensions.html#utf-8-offsets
28 ## Configuration in `initializationOptions`
30 **Upstream Issue:** https://github.com/microsoft/language-server-protocol/issues/567
32 The `initializationOptions` field of the `InitializeParams` of the initialization request should contain the `"rust-analyzer"` section of the configuration.
34 `rust-analyzer` normally sends a `"workspace/configuration"` request with `{ "items": ["rust-analyzer"] }` payload.
35 However, the server can't do this during initialization.
36 At the same time some essential configuration parameters are needed early on, before servicing requests.
37 For this reason, we ask that `initializationOptions` contains the configuration, as if the server did make a `"workspace/configuration"` request.
39 If a language client does not know about `rust-analyzer`'s configuration options it can get sensible defaults by doing any of the following:
40 * Not sending `initializationOptions`
41 * Sending `"initializationOptions": null`
42 * Sending `"initializationOptions": {}`
46 **Upstream Issue:** https://github.com/microsoft/language-server-protocol/issues/724
48 **Experimental Client Capability:** `{ "snippetTextEdit": boolean }`
50 If this capability is set, `WorkspaceEdit`s returned from `codeAction` requests might contain `SnippetTextEdit`s instead of usual `TextEdit`s:
53 interface SnippetTextEdit extends TextEdit {
54 insertTextFormat?: InsertTextFormat;
55 annotationId?: ChangeAnnotationIdentifier;
60 export interface TextDocumentEdit {
61 textDocument: OptionalVersionedTextDocumentIdentifier;
62 edits: (TextEdit | SnippetTextEdit)[];
66 When applying such code action, the editor should insert snippet, with tab stops and placeholder.
67 At the moment, rust-analyzer guarantees that only a single edit will have `InsertTextFormat.Snippet`.
71 "Add `derive`" code action transforms `struct S;` into `#[derive($0)] struct S;`
73 ### Unresolved Questions
75 * Where exactly are `SnippetTextEdit`s allowed (only in code actions at the moment)?
76 * Can snippets span multiple files (so far, no)?
78 ## `CodeAction` Groups
80 **Upstream Issue:** https://github.com/microsoft/language-server-protocol/issues/994
82 **Experimental Client Capability:** `{ "codeActionGroup": boolean }`
84 If this capability is set, `CodeAction`s returned from the server contain an additional field, `group`:
87 interface CodeAction {
94 All code-actions with the same `group` should be grouped under single (extendable) entry in lightbulb menu.
95 The set of actions `[ { title: "foo" }, { group: "frobnicate", title: "bar" }, { group: "frobnicate", title: "baz" }]` should be rendered as
101 +-------------+-----+
102 | frobnicate >| bar |
103 +-------------+-----+
108 Alternatively, selecting `frobnicate` could present a user with an additional menu to choose between `bar` and `baz`.
114 let x: Entry/*cursor here*/ = todo!();
118 Invoking code action at this position will yield two code actions for importing `Entry` from either `collections::HashMap` or `collection::BTreeMap`, grouped under a single "import" group.
120 ### Unresolved Questions
122 * Is a fixed two-level structure enough?
123 * Should we devise a general way to encode custom interaction protocols for GUI refactorings?
127 **Upstream Issue:** https://github.com/microsoft/language-server-protocol/issues/1002
129 **Experimental Server Capability:** `{ "parentModule": boolean }`
131 This request is sent from client to server to handle "Goto Parent Module" editor action.
133 **Method:** `experimental/parentModule`
135 **Request:** `TextDocumentPositionParams`
137 **Response:** `Location | Location[] | LocationLink[] | null`
150 `experimental/parentModule` returns a single `Link` to the `mod foo;` declaration.
152 ### Unresolved Question
154 * An alternative would be to use a more general "gotoSuper" request, which would work for super methods, super classes and super modules.
155 This is the approach IntelliJ Rust is taking.
156 However, experience shows that super module (which generally has a feeling of navigation between files) should be separate.
157 If you want super module, but the cursor happens to be inside an overridden function, the behavior with single "gotoSuper" request is surprising.
161 **Upstream Issue:** https://github.com/microsoft/language-server-protocol/issues/992
163 **Experimental Server Capability:** `{ "joinLines": boolean }`
165 This request is sent from client to server to handle "Join Lines" editor action.
167 **Method:** `experimental/joinLines`
172 interface JoinLinesParams {
173 textDocument: TextDocumentIdentifier,
174 /// Currently active selections/cursor offsets.
175 /// This is an array to support multiple cursors.
180 **Response:** `TextEdit[]`
186 /*cursor here*/let x = {
192 `experimental/joinLines` yields (curly braces are automagically removed)
200 ### Unresolved Question
202 * What is the position of the cursor after `joinLines`?
203 Currently, this is left to editor's discretion, but it might be useful to specify on the server via snippets.
204 However, it then becomes unclear how it works with multi cursor.
208 **Upstream Issue:** https://github.com/microsoft/language-server-protocol/issues/1001
210 **Experimental Server Capability:** `{ "onEnter": boolean }`
212 This request is sent from client to server to handle the <kbd>Enter</kbd> key press.
214 **Method:** `experimental/onEnter`
216 **Request:**: `TextDocumentPositionParams`
228 // Some /*cursor here*/ docs
233 `experimental/onEnter` returns the following snippet
243 The primary goal of `onEnter` is to handle automatic indentation when opening a new line.
244 This is not yet implemented.
245 The secondary goal is to handle fixing up syntax, like continuing doc strings and comments, and escaping `\n` in string literals.
247 As proper cursor positioning is raison-d'etat for `onEnter`, it uses `SnippetTextEdit`.
249 ### Unresolved Question
251 * How to deal with synchronicity of the request?
252 One option is to require the client to block until the server returns the response.
253 Another option is to do a OT-style merging of edits from client and server.
254 A third option is to do a record-replay: client applies heuristic on enter immediately, then applies all user's keypresses.
255 When the server is ready with the response, the client rollbacks all the changes and applies the recorded actions on top of the correct response.
256 * How to deal with multiple carets?
257 * Should we extend this to arbitrary typed events and not just `onEnter`?
259 ## Structural Search Replace (SSR)
261 **Experimental Server Capability:** `{ "ssr": boolean }`
263 This request is sent from client to server to handle structural search replace -- automated syntax tree based transformation of the source.
265 **Method:** `experimental/ssr`
270 interface SsrParams {
272 /// The specific syntax is specified outside of the protocol.
274 /// If true, only check the syntax of the query and don't compute the actual edit.
276 /// The current text document. This and `position` will be used to determine in what scope
277 /// paths in `query` should be resolved.
278 textDocument: TextDocumentIdentifier;
279 /// Position where SSR was invoked.
281 /// Current selections. Search/replace will be restricted to these if non-empty.
294 SSR with query `foo($a, $b) ==>> ($a).foo($b)` will transform, eg `foo(y + 5, z)` into `(y + 5).foo(z)`.
296 ### Unresolved Question
298 * Probably needs search without replace mode
299 * Needs a way to limit the scope to certain files.
303 **Upstream Issue:** https://github.com/microsoft/language-server-protocol/issues/999
305 **Experimental Server Capability:** `{ "matchingBrace": boolean }`
307 This request is sent from client to server to handle "Matching Brace" editor action.
309 **Method:** `experimental/matchingBrace`
314 interface MatchingBraceParams {
315 textDocument: TextDocumentIdentifier,
316 /// Position for each cursor
317 positions: Position[],
331 let x: Vec<()>/*cursor here*/ = vec![]
335 `experimental/matchingBrace` yields the position of `<`.
336 In many cases, matching braces can be handled by the editor.
337 However, some cases (like disambiguating between generics and comparison operations) need a real parser.
338 Moreover, it would be cool if editors didn't need to implement even basic language parsing
340 ### Unresolved Question
342 * Should we return a nested brace structure, to allow paredit-like actions of jump *out* of the current brace pair?
343 This is how `SelectionRange` request works.
344 * Alternatively, should we perhaps flag certain `SelectionRange`s as being brace pairs?
348 **Upstream Issue:** https://github.com/microsoft/language-server-protocol/issues/944
350 **Experimental Server Capability:** `{ "runnables": { "kinds": string[] } }`
352 This request is sent from client to server to get the list of things that can be run (tests, binaries, `cargo check -p`).
354 **Method:** `experimental/runnables`
359 interface RunnablesParams {
360 textDocument: TextDocumentIdentifier;
361 /// If null, compute runnables for the whole file.
366 **Response:** `Runnable[]`
371 /// If this Runnable is associated with a specific function/module, etc, the location of this item
372 location?: LocationLink;
373 /// Running things is necessary technology specific, `kind` needs to be advertised via server capabilities,
374 // the type of `args` is specific to `kind`. The actual running is handled by the client.
380 rust-analyzer supports only one `kind`, `"cargo"`. The `args` for `"cargo"` look like this:
384 workspaceRoot?: string;
386 cargoExtraArgs: string[];
387 executableArgs: string[];
388 expectTest?: boolean;
389 overrideCargo?: string;
393 ## Open External Documentation
395 This request is sent from client to server to get a URL to documentation for the symbol under the cursor, if available.
397 **Method** `experimental/externalDocs`
399 **Request:**: `TextDocumentPositionParams`
401 **Response** `string | null`
406 **Method:** `rust-analyzer/analyzerStatus`
411 interface AnalyzerStatusParams {
412 /// If specified, show dependencies of the current file.
413 textDocument?: TextDocumentIdentifier;
417 **Response:** `string`
419 Returns internal status message, mostly for debugging purposes.
423 **Method:** `rust-analyzer/reloadWorkspace`
429 Reloads project information (that is, re-executes `cargo metadata`).
433 **Experimental Client Capability:** `{ "serverStatusNotification": boolean }`
435 **Method:** `experimental/serverStatus`
440 interface ServerStatusParams {
441 /// `ok` means that the server is completely functional.
443 /// `warning` means that the server is partially functional.
444 /// It can answer correctly to most requests, but some results
445 /// might be wrong due to, for example, some missing dependencies.
447 /// `error` means that the server is not functional. For example,
448 /// there's a fatal build configuration problem. The server might
449 /// still give correct answers to simple requests, but most results
450 /// will be incomplete or wrong.
451 health: "ok" | "warning" | "error",
452 /// Is there any pending background work which might change the status?
453 /// For example, are dependencies being downloaded?
455 /// Explanatory message to show on hover.
460 This notification is sent from server to client.
461 The client can use it to display *persistent* status to the user (in modline).
462 It is similar to the `showMessage`, but is intended for stares rather than point-in-time events.
464 Note that this functionality is intended primarily to inform the end user about the state of the server.
465 In particular, it's valid for the client to completely ignore this extension.
466 Clients are discouraged from but are allowed to use the `health` status to decide if it's worth sending a request to the server.
470 **Method:** `rust-analyzer/syntaxTree`
475 interface SyntaxTreeParams {
476 textDocument: TextDocumentIdentifier,
481 **Response:** `string`
483 Returns textual representation of a parse tree for the file/selected region.
484 Primarily for debugging, but very useful for all people working on rust-analyzer itself.
488 **Method:** `rust-analyzer/viewHir`
490 **Request:** `TextDocumentPositionParams`
492 **Response:** `string`
494 Returns a textual representation of the HIR of the function containing the cursor.
495 For debugging or when working on rust-analyzer itself.
499 **Method:** `rust-analyzer/viewItemTree`
504 interface ViewItemTreeParams {
505 textDocument: TextDocumentIdentifier,
509 **Response:** `string`
511 Returns a textual representation of the `ItemTree` of the currently open file, for debugging.
515 **Method:** `rust-analyzer/viewCrateGraph`
520 interface ViewCrateGraphParams {
525 **Response:** `string`
527 Renders rust-analyzer's crate graph as an SVG image.
529 If `full` is `true`, the graph includes non-workspace crates (crates.io dependencies as well as sysroot crates).
531 ## Shuffle Crate Graph
533 **Method:** `rust-analyzer/shuffleCrateGraph`
537 Shuffles the crate IDs in the crate graph, for debugging purposes.
541 **Method:** `rust-analyzer/expandMacro`
546 interface ExpandMacroParams {
547 textDocument: TextDocumentIdentifier,
555 interface ExpandedMacro {
561 Expands macro call at a given position.
565 **Method:** `experimental/inlayHints`
567 This request is sent from client to server to render "inlay hints" -- virtual text inserted into editor to show things like inferred types.
568 Generally, the client should re-query inlay hints after every modification.
569 Until it gets upstreamed, this follows the VS Code API.
570 Upstream issues: https://github.com/microsoft/language-server-protocol/issues/956 , https://github.com/rust-analyzer/rust-analyzer/issues/2797
575 interface InlayHintsParams {
576 textDocument: TextDocumentIdentifier,
580 **Response:** `InlayHint[]`
583 interface InlayHint {
585 label: string | InlayHintLabelPart[];
586 tooltip?: string | MarkdownString | undefined;
587 kind?: InlayHintKind;
588 paddingLeft?: boolean;
589 paddingRight?: boolean;
595 **Experimental Client Capability:** `{ "hoverActions": boolean }`
597 If this capability is set, `Hover` request returned from the server might contain an additional field, `actions`:
602 actions?: CommandLinkGroup[];
605 interface CommandLink extends Command {
607 * A tooltip for the command, when represented in the UI.
612 interface CommandLinkGroup {
614 commands: CommandLink[];
618 Such actions on the client side are appended to a hover bottom as command links:
620 +-----------------------------+
623 +-----------------------------+
624 | _Action1_ | _Action2_ | <- first group, no TITLE
625 +-----------------------------+
626 | TITLE _Action1_ | _Action2_ | <- second group
627 +-----------------------------+
633 **Upstream Issue:** https://github.com/rust-analyzer/rust-analyzer/issues/6462
635 **Experimental Server Capability:** `{ "openCargoToml": boolean }`
637 This request is sent from client to server to open the current project's Cargo.toml
639 **Method:** `experimental/openCargoToml`
641 **Request:** `OpenCargoTomlParams`
643 **Response:** `Location | null`
656 `experimental/openCargoToml` returns a single `Link` to the start of the `[package]` keyword.
660 This request is sent from client to server to get the list of tests for the specified position.
662 **Method:** `rust-analyzer/relatedTests`
664 **Request:** `TextDocumentPositionParams`
666 **Response:** `TestInfo[]`
676 **Upstream Issue:** https://github.com/microsoft/language-server-protocol/issues/377
678 **Experimental Server Capability:** { "hoverRange": boolean }
680 This extension allows passing a `Range` as a `position` field of `HoverParams`.
681 The primary use-case is to use the hover request to show the type of the expression currently selected.
684 interface HoverParams extends WorkDoneProgressParams {
685 textDocument: TextDocumentIdentifier;
686 position: Range | Position;
689 Whenever the client sends a `Range`, it is understood as the current selection and any hover included in the range will show the type of the expression if possible.
695 let expression = $01 + 2 * 3$0;
699 Triggering a hover inside the selection above will show a result of `i32`.
703 **Upstream Issue:** https://github.com/rust-analyzer/rust-analyzer/issues/6823
705 This request is sent from client to server to move item under cursor or selection in some direction.
707 **Method:** `experimental/moveItem`
709 **Request:** `MoveItemParams`
711 **Response:** `SnippetTextEdit[]`
714 export interface MoveItemParams {
715 textDocument: TextDocumentIdentifier,
720 export const enum Direction {
726 ## Workspace Symbols Filtering
728 **Upstream Issue:** https://github.com/microsoft/language-server-protocol/issues/941
730 **Experimental Server Capability:** `{ "workspaceSymbolScopeKindFiltering": boolean }`
732 Extends the existing `workspace/symbol` request with ability to filter symbols by broad scope and kind of symbol.
733 If this capability is set, `workspace/symbol` parameter gains two new optional fields:
737 interface WorkspaceSymbolParams {
739 * Return only the symbols defined in the specified scope.
741 searchScope?: WorkspaceSymbolSearchScope;
743 * Return only the symbols of specified kinds.
745 searchKind?: WorkspaceSymbolSearchKind;
749 const enum WorkspaceSymbolSearchScope {
750 Workspace = "workspace",
751 WorkspaceAndDependencies = "workspaceAndDependencies"
754 const enum WorkspaceSymbolSearchKind {
755 OnlyTypes = "onlyTypes",
756 AllSymbols = "allSymbols"
762 **Upstream Issue:** https://github.com/microsoft/language-server-protocol/issues/642
764 **Experimental Client Capability:** `{ "commands?": ClientCommandOptions }`
766 Certain LSP types originating on the server, notably code lenses, embed commands.
767 Commands can be serviced either by the server or by the client.
768 However, the server doesn't know which commands are available on the client.
770 This extensions allows the client to communicate this info.
774 export interface ClientCommandOptions {
776 * The commands to be executed on the client