Trait tower_lsp::LanguageServer
source · pub trait LanguageServer:
Send
+ Sync
+ 'static {
Show 63 methods
// Required methods
fn initialize<'life0, 'async_trait>(
&'life0 self,
params: InitializeParams,
) -> Pin<Box<dyn Future<Output = Result<InitializeResult>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait;
fn shutdown<'life0, 'async_trait>(
&'life0 self,
) -> Pin<Box<dyn Future<Output = Result<()>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait;
// Provided methods
fn initialized<'life0, 'async_trait>(
&'life0 self,
params: InitializedParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn did_open<'life0, 'async_trait>(
&'life0 self,
params: DidOpenTextDocumentParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn did_change<'life0, 'async_trait>(
&'life0 self,
params: DidChangeTextDocumentParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn will_save<'life0, 'async_trait>(
&'life0 self,
params: WillSaveTextDocumentParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn will_save_wait_until<'life0, 'async_trait>(
&'life0 self,
params: WillSaveTextDocumentParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<TextEdit>>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn did_save<'life0, 'async_trait>(
&'life0 self,
params: DidSaveTextDocumentParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn did_close<'life0, 'async_trait>(
&'life0 self,
params: DidCloseTextDocumentParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn goto_declaration<'life0, 'async_trait>(
&'life0 self,
params: GotoDeclarationParams,
) -> Pin<Box<dyn Future<Output = Result<Option<GotoDeclarationResponse>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn goto_definition<'life0, 'async_trait>(
&'life0 self,
params: GotoDefinitionParams,
) -> Pin<Box<dyn Future<Output = Result<Option<GotoDefinitionResponse>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn goto_type_definition<'life0, 'async_trait>(
&'life0 self,
params: GotoTypeDefinitionParams,
) -> Pin<Box<dyn Future<Output = Result<Option<GotoTypeDefinitionResponse>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn goto_implementation<'life0, 'async_trait>(
&'life0 self,
params: GotoImplementationParams,
) -> Pin<Box<dyn Future<Output = Result<Option<GotoImplementationResponse>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn references<'life0, 'async_trait>(
&'life0 self,
params: ReferenceParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<Location>>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn prepare_call_hierarchy<'life0, 'async_trait>(
&'life0 self,
params: CallHierarchyPrepareParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<CallHierarchyItem>>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn incoming_calls<'life0, 'async_trait>(
&'life0 self,
params: CallHierarchyIncomingCallsParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<CallHierarchyIncomingCall>>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn outgoing_calls<'life0, 'async_trait>(
&'life0 self,
params: CallHierarchyOutgoingCallsParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<CallHierarchyOutgoingCall>>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn prepare_type_hierarchy<'life0, 'async_trait>(
&'life0 self,
params: TypeHierarchyPrepareParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<TypeHierarchyItem>>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn supertypes<'life0, 'async_trait>(
&'life0 self,
params: TypeHierarchySupertypesParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<TypeHierarchyItem>>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn subtypes<'life0, 'async_trait>(
&'life0 self,
params: TypeHierarchySubtypesParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<TypeHierarchyItem>>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn document_highlight<'life0, 'async_trait>(
&'life0 self,
params: DocumentHighlightParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<DocumentHighlight>>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn document_link<'life0, 'async_trait>(
&'life0 self,
params: DocumentLinkParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<DocumentLink>>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn document_link_resolve<'life0, 'async_trait>(
&'life0 self,
params: DocumentLink,
) -> Pin<Box<dyn Future<Output = Result<DocumentLink>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn hover<'life0, 'async_trait>(
&'life0 self,
params: HoverParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Hover>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn code_lens<'life0, 'async_trait>(
&'life0 self,
params: CodeLensParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<CodeLens>>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn code_lens_resolve<'life0, 'async_trait>(
&'life0 self,
params: CodeLens,
) -> Pin<Box<dyn Future<Output = Result<CodeLens>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn folding_range<'life0, 'async_trait>(
&'life0 self,
params: FoldingRangeParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<FoldingRange>>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn selection_range<'life0, 'async_trait>(
&'life0 self,
params: SelectionRangeParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<SelectionRange>>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn document_symbol<'life0, 'async_trait>(
&'life0 self,
params: DocumentSymbolParams,
) -> Pin<Box<dyn Future<Output = Result<Option<DocumentSymbolResponse>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn semantic_tokens_full<'life0, 'async_trait>(
&'life0 self,
params: SemanticTokensParams,
) -> Pin<Box<dyn Future<Output = Result<Option<SemanticTokensResult>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn semantic_tokens_full_delta<'life0, 'async_trait>(
&'life0 self,
params: SemanticTokensDeltaParams,
) -> Pin<Box<dyn Future<Output = Result<Option<SemanticTokensFullDeltaResult>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn semantic_tokens_range<'life0, 'async_trait>(
&'life0 self,
params: SemanticTokensRangeParams,
) -> Pin<Box<dyn Future<Output = Result<Option<SemanticTokensRangeResult>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn inline_value<'life0, 'async_trait>(
&'life0 self,
params: InlineValueParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<InlineValue>>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn inlay_hint<'life0, 'async_trait>(
&'life0 self,
params: InlayHintParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<InlayHint>>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn inlay_hint_resolve<'life0, 'async_trait>(
&'life0 self,
params: InlayHint,
) -> Pin<Box<dyn Future<Output = Result<InlayHint>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn moniker<'life0, 'async_trait>(
&'life0 self,
params: MonikerParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<Moniker>>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn completion<'life0, 'async_trait>(
&'life0 self,
params: CompletionParams,
) -> Pin<Box<dyn Future<Output = Result<Option<CompletionResponse>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn completion_resolve<'life0, 'async_trait>(
&'life0 self,
params: CompletionItem,
) -> Pin<Box<dyn Future<Output = Result<CompletionItem>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn diagnostic<'life0, 'async_trait>(
&'life0 self,
params: DocumentDiagnosticParams,
) -> Pin<Box<dyn Future<Output = Result<DocumentDiagnosticReportResult>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn workspace_diagnostic<'life0, 'async_trait>(
&'life0 self,
params: WorkspaceDiagnosticParams,
) -> Pin<Box<dyn Future<Output = Result<WorkspaceDiagnosticReportResult>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn signature_help<'life0, 'async_trait>(
&'life0 self,
params: SignatureHelpParams,
) -> Pin<Box<dyn Future<Output = Result<Option<SignatureHelp>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn code_action<'life0, 'async_trait>(
&'life0 self,
params: CodeActionParams,
) -> Pin<Box<dyn Future<Output = Result<Option<CodeActionResponse>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn code_action_resolve<'life0, 'async_trait>(
&'life0 self,
params: CodeAction,
) -> Pin<Box<dyn Future<Output = Result<CodeAction>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn document_color<'life0, 'async_trait>(
&'life0 self,
params: DocumentColorParams,
) -> Pin<Box<dyn Future<Output = Result<Vec<ColorInformation>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn color_presentation<'life0, 'async_trait>(
&'life0 self,
params: ColorPresentationParams,
) -> Pin<Box<dyn Future<Output = Result<Vec<ColorPresentation>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn formatting<'life0, 'async_trait>(
&'life0 self,
params: DocumentFormattingParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<TextEdit>>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn range_formatting<'life0, 'async_trait>(
&'life0 self,
params: DocumentRangeFormattingParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<TextEdit>>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn on_type_formatting<'life0, 'async_trait>(
&'life0 self,
params: DocumentOnTypeFormattingParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<TextEdit>>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn rename<'life0, 'async_trait>(
&'life0 self,
params: RenameParams,
) -> Pin<Box<dyn Future<Output = Result<Option<WorkspaceEdit>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn prepare_rename<'life0, 'async_trait>(
&'life0 self,
params: TextDocumentPositionParams,
) -> Pin<Box<dyn Future<Output = Result<Option<PrepareRenameResponse>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn linked_editing_range<'life0, 'async_trait>(
&'life0 self,
params: LinkedEditingRangeParams,
) -> Pin<Box<dyn Future<Output = Result<Option<LinkedEditingRanges>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn symbol<'life0, 'async_trait>(
&'life0 self,
params: WorkspaceSymbolParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<SymbolInformation>>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn symbol_resolve<'life0, 'async_trait>(
&'life0 self,
params: WorkspaceSymbol,
) -> Pin<Box<dyn Future<Output = Result<WorkspaceSymbol>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn did_change_configuration<'life0, 'async_trait>(
&'life0 self,
params: DidChangeConfigurationParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn did_change_workspace_folders<'life0, 'async_trait>(
&'life0 self,
params: DidChangeWorkspaceFoldersParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn will_create_files<'life0, 'async_trait>(
&'life0 self,
params: CreateFilesParams,
) -> Pin<Box<dyn Future<Output = Result<Option<WorkspaceEdit>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn did_create_files<'life0, 'async_trait>(
&'life0 self,
params: CreateFilesParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn will_rename_files<'life0, 'async_trait>(
&'life0 self,
params: RenameFilesParams,
) -> Pin<Box<dyn Future<Output = Result<Option<WorkspaceEdit>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn did_rename_files<'life0, 'async_trait>(
&'life0 self,
params: RenameFilesParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn will_delete_files<'life0, 'async_trait>(
&'life0 self,
params: DeleteFilesParams,
) -> Pin<Box<dyn Future<Output = Result<Option<WorkspaceEdit>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn did_delete_files<'life0, 'async_trait>(
&'life0 self,
params: DeleteFilesParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn did_change_watched_files<'life0, 'async_trait>(
&'life0 self,
params: DidChangeWatchedFilesParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
fn execute_command<'life0, 'async_trait>(
&'life0 self,
params: ExecuteCommandParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Value>>> + Send + 'async_trait>>
where Self: 'async_trait,
'life0: 'async_trait { ... }
}Expand description
Trait implemented by language server backends.
This interface allows servers adhering to the Language Server Protocol to be implemented in a safe and easily testable way without exposing the low-level implementation details.
Required Methods§
sourcefn initialize<'life0, 'async_trait>(
&'life0 self,
params: InitializeParams,
) -> Pin<Box<dyn Future<Output = Result<InitializeResult>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn initialize<'life0, 'async_trait>(
&'life0 self,
params: InitializeParams,
) -> Pin<Box<dyn Future<Output = Result<InitializeResult>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The initialize request is the first request sent from the client to the server.
This method is guaranteed to only execute once. If the client sends this request to the
server again, the server will respond with JSON-RPC error code -32600 (invalid request).
sourcefn shutdown<'life0, 'async_trait>(
&'life0 self,
) -> Pin<Box<dyn Future<Output = Result<()>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn shutdown<'life0, 'async_trait>(
&'life0 self,
) -> Pin<Box<dyn Future<Output = Result<()>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The shutdown request asks the server to gracefully shut down, but to not exit.
This request is often later followed by an exit notification, which will cause the
server to exit immediately.
This method is guaranteed to only execute once. If the client sends this request to the
server again, the server will respond with JSON-RPC error code -32600 (invalid request).
Provided Methods§
sourcefn initialized<'life0, 'async_trait>(
&'life0 self,
params: InitializedParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn initialized<'life0, 'async_trait>(
&'life0 self,
params: InitializedParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The initialized notification is sent from the client to the server after the client
received the result of the initialize request but before the client sends anything else.
The server can use the initialized notification, for example, to dynamically register
capabilities with the client.
sourcefn did_open<'life0, 'async_trait>(
&'life0 self,
params: DidOpenTextDocumentParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn did_open<'life0, 'async_trait>(
&'life0 self,
params: DidOpenTextDocumentParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/didOpen notification is sent from the client to the server to signal
that a new text document has been opened by the client.
The document’s truth is now managed by the client and the server must not try to read the document’s truth using the document’s URI. “Open” in this sense means it is managed by the client. It doesn’t necessarily mean that its content is presented in an editor.
sourcefn did_change<'life0, 'async_trait>(
&'life0 self,
params: DidChangeTextDocumentParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn did_change<'life0, 'async_trait>(
&'life0 self,
params: DidChangeTextDocumentParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/didChange notification is sent from the client to the server to signal
changes to a text document.
This notification will contain a distinct version tag and a list of edits made to the document for the server to interpret.
sourcefn will_save<'life0, 'async_trait>(
&'life0 self,
params: WillSaveTextDocumentParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn will_save<'life0, 'async_trait>(
&'life0 self,
params: WillSaveTextDocumentParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/willSave notification is sent from the client to the server before the
document is actually saved.
sourcefn will_save_wait_until<'life0, 'async_trait>(
&'life0 self,
params: WillSaveTextDocumentParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<TextEdit>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn will_save_wait_until<'life0, 'async_trait>(
&'life0 self,
params: WillSaveTextDocumentParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<TextEdit>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/willSaveWaitUntil request is sent from the client to the server before
the document is actually saved.
The request can return an array of TextEdits which will be applied to the text document
before it is saved.
Please note that clients might drop results if computing the text edits took too long or if a server constantly fails on this request. This is done to keep the save fast and reliable.
sourcefn did_save<'life0, 'async_trait>(
&'life0 self,
params: DidSaveTextDocumentParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn did_save<'life0, 'async_trait>(
&'life0 self,
params: DidSaveTextDocumentParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/didSave notification is sent from the client to the server when the
document was saved in the client.
sourcefn did_close<'life0, 'async_trait>(
&'life0 self,
params: DidCloseTextDocumentParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn did_close<'life0, 'async_trait>(
&'life0 self,
params: DidCloseTextDocumentParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/didClose notification is sent from the client to the server when the
document got closed in the client.
The document’s truth now exists where the document’s URI points to (e.g. if the document’s URI is a file URI, the truth now exists on disk).
sourcefn goto_declaration<'life0, 'async_trait>(
&'life0 self,
params: GotoDeclarationParams,
) -> Pin<Box<dyn Future<Output = Result<Option<GotoDeclarationResponse>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn goto_declaration<'life0, 'async_trait>(
&'life0 self,
params: GotoDeclarationParams,
) -> Pin<Box<dyn Future<Output = Result<Option<GotoDeclarationResponse>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/declaration request asks the server for the declaration location of a
symbol at a given text document position.
§Compatibility
This request was introduced in specification version 3.14.0.
The GotoDeclarationResponse::Link return value
was introduced in specification version 3.14.0 and requires client-side support in order to
be used. It can be returned if the client set the following field to true in the
initialize method:
InitializeParams::capabilities::text_document::declaration::link_support
sourcefn goto_definition<'life0, 'async_trait>(
&'life0 self,
params: GotoDefinitionParams,
) -> Pin<Box<dyn Future<Output = Result<Option<GotoDefinitionResponse>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn goto_definition<'life0, 'async_trait>(
&'life0 self,
params: GotoDefinitionParams,
) -> Pin<Box<dyn Future<Output = Result<Option<GotoDefinitionResponse>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/definition request asks the server for the definition location of a
symbol at a given text document position.
§Compatibility
The GotoDefinitionResponse::Link return value
was introduced in specification version 3.14.0 and requires client-side support in order to
be used. It can be returned if the client set the following field to true in the
initialize method:
InitializeParams::capabilities::text_document::definition::link_support
sourcefn goto_type_definition<'life0, 'async_trait>(
&'life0 self,
params: GotoTypeDefinitionParams,
) -> Pin<Box<dyn Future<Output = Result<Option<GotoTypeDefinitionResponse>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn goto_type_definition<'life0, 'async_trait>(
&'life0 self,
params: GotoTypeDefinitionParams,
) -> Pin<Box<dyn Future<Output = Result<Option<GotoTypeDefinitionResponse>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/typeDefinition request asks the server for the type definition location of
a symbol at a given text document position.
§Compatibility
This request was introduced in specification version 3.6.0.
The GotoTypeDefinitionResponse::Link return
value was introduced in specification version 3.14.0 and requires client-side support in
order to be used. It can be returned if the client set the following field to true in the
initialize method:
InitializeParams::capabilities::text_document::type_definition::link_support
sourcefn goto_implementation<'life0, 'async_trait>(
&'life0 self,
params: GotoImplementationParams,
) -> Pin<Box<dyn Future<Output = Result<Option<GotoImplementationResponse>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn goto_implementation<'life0, 'async_trait>(
&'life0 self,
params: GotoImplementationParams,
) -> Pin<Box<dyn Future<Output = Result<Option<GotoImplementationResponse>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/implementation request is sent from the client to the server to resolve
the implementation location of a symbol at a given text document position.
§Compatibility
This request was introduced in specification version 3.6.0.
The GotoImplementationResponse::Link
return value was introduced in specification version 3.14.0 and requires client-side
support in order to be used. It can be returned if the client set the following field to
true in the initialize method:
InitializeParams::capabilities::text_document::implementation::link_support
sourcefn references<'life0, 'async_trait>(
&'life0 self,
params: ReferenceParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<Location>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn references<'life0, 'async_trait>(
&'life0 self,
params: ReferenceParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<Location>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/references request is sent from the client to the server to resolve
project-wide references for the symbol denoted by the given text document position.
sourcefn prepare_call_hierarchy<'life0, 'async_trait>(
&'life0 self,
params: CallHierarchyPrepareParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<CallHierarchyItem>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn prepare_call_hierarchy<'life0, 'async_trait>(
&'life0 self,
params: CallHierarchyPrepareParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<CallHierarchyItem>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/prepareCallHierarchy request is sent from the client to the server to
return a call hierarchy for the language element of given text document positions.
The call hierarchy requests are executed in two steps:
- First, a call hierarchy item is resolved for the given text document position (this method).
- For a call hierarchy item, the incoming or outgoing call hierarchy items are resolved
inside
incoming_callsandoutgoing_calls, respectively.
§Compatibility
This request was introduced in specification version 3.16.0.
sourcefn incoming_calls<'life0, 'async_trait>(
&'life0 self,
params: CallHierarchyIncomingCallsParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<CallHierarchyIncomingCall>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn incoming_calls<'life0, 'async_trait>(
&'life0 self,
params: CallHierarchyIncomingCallsParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<CallHierarchyIncomingCall>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The callHierarchy/incomingCalls request is sent from the client to the server to
resolve incoming calls for a given call hierarchy item.
The request doesn’t define its own client and server capabilities. It is only issued if a
server registers for the textDocument/prepareCallHierarchy request.
§Compatibility
This request was introduced in specification version 3.16.0.
sourcefn outgoing_calls<'life0, 'async_trait>(
&'life0 self,
params: CallHierarchyOutgoingCallsParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<CallHierarchyOutgoingCall>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn outgoing_calls<'life0, 'async_trait>(
&'life0 self,
params: CallHierarchyOutgoingCallsParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<CallHierarchyOutgoingCall>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The callHierarchy/outgoingCalls request is sent from the client to the server to
resolve outgoing calls for a given call hierarchy item.
The request doesn’t define its own client and server capabilities. It is only issued if a
server registers for the textDocument/prepareCallHierarchy request.
§Compatibility
This request was introduced in specification version 3.16.0.
sourcefn prepare_type_hierarchy<'life0, 'async_trait>(
&'life0 self,
params: TypeHierarchyPrepareParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<TypeHierarchyItem>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn prepare_type_hierarchy<'life0, 'async_trait>(
&'life0 self,
params: TypeHierarchyPrepareParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<TypeHierarchyItem>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/prepareTypeHierarchy request is sent from the client to the server to
return a type hierarchy for the language element of given text document positions.
Returns Ok(None) if the server couldn’t infer a valid type from the position.
The type hierarchy requests are executed in two steps:
- First, a type hierarchy item is prepared for the given text document position.
- For a type hierarchy item, the supertype or subtype type hierarchy items are resolved in
supertypesandsubtypes, respectively.
§Compatibility
This request was introduced in specification version 3.17.0.
sourcefn supertypes<'life0, 'async_trait>(
&'life0 self,
params: TypeHierarchySupertypesParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<TypeHierarchyItem>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn supertypes<'life0, 'async_trait>(
&'life0 self,
params: TypeHierarchySupertypesParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<TypeHierarchyItem>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The [typeHierarchy/supertypes] request is sent from the client to the server to resolve
the supertypes for a given type hierarchy item.
Returns Ok(None) if the server couldn’t infer a valid type from item in params.
The request doesn’t define its own client and server capabilities. It is only issued if a
server registers for the textDocument/prepareTypeHierarchy request.
§Compatibility
This request was introduced in specification version 3.17.0.
sourcefn subtypes<'life0, 'async_trait>(
&'life0 self,
params: TypeHierarchySubtypesParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<TypeHierarchyItem>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn subtypes<'life0, 'async_trait>(
&'life0 self,
params: TypeHierarchySubtypesParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<TypeHierarchyItem>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The [typeHierarchy/subtypes] request is sent from the client to the server to resolve
the subtypes for a given type hierarchy item.
Returns Ok(None) if the server couldn’t infer a valid type from item in params.
The request doesn’t define its own client and server capabilities. It is only issued if a
server registers for the textDocument/prepareTypeHierarchy request.
§Compatibility
This request was introduced in specification version 3.17.0.
sourcefn document_highlight<'life0, 'async_trait>(
&'life0 self,
params: DocumentHighlightParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<DocumentHighlight>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn document_highlight<'life0, 'async_trait>(
&'life0 self,
params: DocumentHighlightParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<DocumentHighlight>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/documentHighlight request is sent from the client to the server to
resolve appropriate highlights for a given text document position.
For programming languages, this usually highlights all textual references to the symbol scoped to this file.
This request differs slightly from textDocument/references in that this one is allowed to
be more fuzzy.
sourcefn document_link<'life0, 'async_trait>(
&'life0 self,
params: DocumentLinkParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<DocumentLink>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn document_link<'life0, 'async_trait>(
&'life0 self,
params: DocumentLinkParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<DocumentLink>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/documentLink request is sent from the client to the server to request
the location of links in a document.
A document link is a range in a text document that links to an internal or external resource, like another text document or a web site.
§Compatibility
The DocumentLink::tooltip field was introduced in specification version 3.15.0 and
requires client-side support in order to be used. It can be returned if the client set the
following field to true in the initialize method:
InitializeParams::capabilities::text_document::document_link::tooltip_support
sourcefn document_link_resolve<'life0, 'async_trait>(
&'life0 self,
params: DocumentLink,
) -> Pin<Box<dyn Future<Output = Result<DocumentLink>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn document_link_resolve<'life0, 'async_trait>(
&'life0 self,
params: DocumentLink,
) -> Pin<Box<dyn Future<Output = Result<DocumentLink>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The documentLink/resolve request is sent from the client to the server to resolve the
target of a given document link.
A document link is a range in a text document that links to an internal or external resource, like another text document or a web site.
sourcefn hover<'life0, 'async_trait>(
&'life0 self,
params: HoverParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Hover>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn hover<'life0, 'async_trait>(
&'life0 self,
params: HoverParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Hover>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/hover request asks the server for hover information at a given text
document position.
Such hover information typically includes type signature information and inline documentation for the symbol at the given text document position.
sourcefn code_lens<'life0, 'async_trait>(
&'life0 self,
params: CodeLensParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<CodeLens>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn code_lens<'life0, 'async_trait>(
&'life0 self,
params: CodeLensParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<CodeLens>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/codeLens request is sent from the client to the server to compute code
lenses for a given text document.
sourcefn code_lens_resolve<'life0, 'async_trait>(
&'life0 self,
params: CodeLens,
) -> Pin<Box<dyn Future<Output = Result<CodeLens>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn code_lens_resolve<'life0, 'async_trait>(
&'life0 self,
params: CodeLens,
) -> Pin<Box<dyn Future<Output = Result<CodeLens>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The codeLens/resolve request is sent from the client to the server to resolve the
command for a given code lens item.
sourcefn folding_range<'life0, 'async_trait>(
&'life0 self,
params: FoldingRangeParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<FoldingRange>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn folding_range<'life0, 'async_trait>(
&'life0 self,
params: FoldingRangeParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<FoldingRange>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/foldingRange request is sent from the client to the server to return
all folding ranges found in a given text document.
§Compatibility
This request was introduced in specification version 3.10.0.
sourcefn selection_range<'life0, 'async_trait>(
&'life0 self,
params: SelectionRangeParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<SelectionRange>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn selection_range<'life0, 'async_trait>(
&'life0 self,
params: SelectionRangeParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<SelectionRange>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/selectionRange request is sent from the client to the server to return
suggested selection ranges at an array of given positions. A selection range is a range
around the cursor position which the user might be interested in selecting.
A selection range in the return array is for the position in the provided parameters at the
same index. Therefore params.positions[i] must be contained in result[i].range.
§Compatibility
This request was introduced in specification version 3.15.0.
sourcefn document_symbol<'life0, 'async_trait>(
&'life0 self,
params: DocumentSymbolParams,
) -> Pin<Box<dyn Future<Output = Result<Option<DocumentSymbolResponse>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn document_symbol<'life0, 'async_trait>(
&'life0 self,
params: DocumentSymbolParams,
) -> Pin<Box<dyn Future<Output = Result<Option<DocumentSymbolResponse>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/documentSymbol request is sent from the client to the server to
retrieve all symbols found in a given text document.
The returned result is either:
DocumentSymbolResponse::Flatwhich is a flat list of all symbols found in a given text document. Then neither the symbol’s location range nor the symbol’s container name should be used to infer a hierarchy.DocumentSymbolResponse::Nestedwhich is a hierarchy of symbols found in a given text document.
sourcefn semantic_tokens_full<'life0, 'async_trait>(
&'life0 self,
params: SemanticTokensParams,
) -> Pin<Box<dyn Future<Output = Result<Option<SemanticTokensResult>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn semantic_tokens_full<'life0, 'async_trait>(
&'life0 self,
params: SemanticTokensParams,
) -> Pin<Box<dyn Future<Output = Result<Option<SemanticTokensResult>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/semanticTokens/full request is sent from the client to the server to
resolve the semantic tokens of a given file.
Semantic tokens are used to add additional color information to a file that depends on
language specific symbol information. A semantic token request usually produces a large
result. The protocol therefore supports encoding tokens with numbers. In addition, optional
support for deltas is available, i.e. semantic_tokens_full_delta.
§Compatibility
This request was introduced in specification version 3.16.0.
sourcefn semantic_tokens_full_delta<'life0, 'async_trait>(
&'life0 self,
params: SemanticTokensDeltaParams,
) -> Pin<Box<dyn Future<Output = Result<Option<SemanticTokensFullDeltaResult>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn semantic_tokens_full_delta<'life0, 'async_trait>(
&'life0 self,
params: SemanticTokensDeltaParams,
) -> Pin<Box<dyn Future<Output = Result<Option<SemanticTokensFullDeltaResult>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/semanticTokens/full/delta request is sent from the client to the server to
resolve the semantic tokens of a given file, returning only the delta.
Similar to semantic_tokens_full, except it returns a
sequence of SemanticTokensEdit to transform a previous result into a new result.
§Compatibility
This request was introduced in specification version 3.16.0.
sourcefn semantic_tokens_range<'life0, 'async_trait>(
&'life0 self,
params: SemanticTokensRangeParams,
) -> Pin<Box<dyn Future<Output = Result<Option<SemanticTokensRangeResult>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn semantic_tokens_range<'life0, 'async_trait>(
&'life0 self,
params: SemanticTokensRangeParams,
) -> Pin<Box<dyn Future<Output = Result<Option<SemanticTokensRangeResult>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/semanticTokens/range request is sent from the client to the server to
resolve the semantic tokens for the visible range of a given file.
When a user opens a file, it can be beneficial to only compute the semantic tokens for the visible range (faster rendering of the tokens in the user interface). If a server can compute these tokens faster than for the whole file, it can implement this method to handle this special case.
See the semantic_tokens_full documentation for more
details.
§Compatibility
This request was introduced in specification version 3.16.0.
sourcefn inline_value<'life0, 'async_trait>(
&'life0 self,
params: InlineValueParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<InlineValue>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn inline_value<'life0, 'async_trait>(
&'life0 self,
params: InlineValueParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<InlineValue>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/inlineValue request is sent from the client to the server to compute
inline values for a given text document that may be rendered in the editor at the end of
lines.
§Compatibility
This request was introduced in specification version 3.17.0.
sourcefn inlay_hint<'life0, 'async_trait>(
&'life0 self,
params: InlayHintParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<InlayHint>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn inlay_hint<'life0, 'async_trait>(
&'life0 self,
params: InlayHintParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<InlayHint>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/inlayHint request is sent from the client to the server to compute
inlay hints for a given (text document, range) tuple that may be rendered in the editor
in place with other text.
§Compatibility
This request was introduced in specification version 3.17.0
sourcefn inlay_hint_resolve<'life0, 'async_trait>(
&'life0 self,
params: InlayHint,
) -> Pin<Box<dyn Future<Output = Result<InlayHint>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn inlay_hint_resolve<'life0, 'async_trait>(
&'life0 self,
params: InlayHint,
) -> Pin<Box<dyn Future<Output = Result<InlayHint>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The inlayHint/resolve request is sent from the client to the server to resolve
additional information for a given inlay hint.
This is usually used to compute the tooltip, location or command properties of an inlay
hint’s label part to avoid its unnecessary computation during the textDocument/inlayHint
request.
Consider a client announces the label.location property as a property that can be
resolved lazily using the client capability:
textDocument.inlayHint.resolveSupport = { properties: ['label.location'] };
then an inlay hint with a label part, but without a location, must be resolved using the
inlayHint/resolve request before it can be used.
§Compatibility
This request was introduced in specification version 3.17.0
sourcefn moniker<'life0, 'async_trait>(
&'life0 self,
params: MonikerParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<Moniker>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn moniker<'life0, 'async_trait>(
&'life0 self,
params: MonikerParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<Moniker>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/moniker request is sent from the client to the server to get the
symbol monikers for a given text document position.
An array of Moniker types is returned as response to indicate possible monikers at the
given location. If no monikers can be calculated, Some(vec![]) or None should be
returned.
§Concept
The Language Server Index Format (LSIF) introduced the concept of symbol monikers to help associate symbols across different indexes. This request adds capability for LSP server implementations to provide the same symbol moniker information given a text document position.
Clients can utilize this method to get the moniker at the current location in a file the user is editing and do further code navigation queries in other services that rely on LSIF indexes and link symbols together.
§Compatibility
This request was introduced in specification version 3.16.0.
sourcefn completion<'life0, 'async_trait>(
&'life0 self,
params: CompletionParams,
) -> Pin<Box<dyn Future<Output = Result<Option<CompletionResponse>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn completion<'life0, 'async_trait>(
&'life0 self,
params: CompletionParams,
) -> Pin<Box<dyn Future<Output = Result<Option<CompletionResponse>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/completion request is sent from the client to the server to compute
completion items at a given cursor position.
If computing full completion items is expensive, servers can additionally provide a handler
for the completion item resolve request (completionItem/resolve). This request is sent
when a completion item is selected in the user interface.
§Compatibility
Since 3.16.0, the client can signal that it can resolve more properties lazily. This is
done using the completion_item.resolve_support client capability which lists all
properties that can be filled in during a completionItem/resolve request.
All other properties (usually sort_text, filter_text, insert_text, and text_edit)
must be provided in the textDocument/completion response and must not be changed during
resolve.
sourcefn completion_resolve<'life0, 'async_trait>(
&'life0 self,
params: CompletionItem,
) -> Pin<Box<dyn Future<Output = Result<CompletionItem>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn completion_resolve<'life0, 'async_trait>(
&'life0 self,
params: CompletionItem,
) -> Pin<Box<dyn Future<Output = Result<CompletionItem>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The completionItem/resolve request is sent from the client to the server to resolve
additional information for a given completion item.
sourcefn diagnostic<'life0, 'async_trait>(
&'life0 self,
params: DocumentDiagnosticParams,
) -> Pin<Box<dyn Future<Output = Result<DocumentDiagnosticReportResult>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn diagnostic<'life0, 'async_trait>(
&'life0 self,
params: DocumentDiagnosticParams,
) -> Pin<Box<dyn Future<Output = Result<DocumentDiagnosticReportResult>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/diagnostic request is sent from the client to the server to ask the
server to compute the diagnostics for a given document.
As with other pull requests, the server is asked to compute the diagnostics for the currently synced version of the document.
The request doesn’t define its own client and server capabilities. It is only issued if a
server registers for the textDocument/diagnostic request.
§Compatibility
This request was introduced in specification version 3.17.0.
sourcefn workspace_diagnostic<'life0, 'async_trait>(
&'life0 self,
params: WorkspaceDiagnosticParams,
) -> Pin<Box<dyn Future<Output = Result<WorkspaceDiagnosticReportResult>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn workspace_diagnostic<'life0, 'async_trait>(
&'life0 self,
params: WorkspaceDiagnosticParams,
) -> Pin<Box<dyn Future<Output = Result<WorkspaceDiagnosticReportResult>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The workspace/diagnostic request is sent from the client to the server to ask the
server to compute workspace wide diagnostics which previously where pushed from the server
to the client.
In contrast to the textDocument/diagnostic request, the workspace request can be
long-running and is not bound to a specific workspace or document state. If the client
supports streaming for the workspace diagnostic pull, it is legal to provide a
textDocument/diagnostic report multiple times for the same document URI. The last one
reported will win over previous reports.
If a client receives a diagnostic report for a document in a workspace diagnostic request for which the client also issues individual document diagnostic pull requests, the client needs to decide which diagnostics win and should be presented. In general:
- Diagnostics for a higher document version should win over those from a lower document version (e.g. note that document versions are steadily increasing).
- Diagnostics from a document pull should win over diagnostics from a workspace pull.
The request doesn’t define its own client and server capabilities. It is only issued if a
server registers for the workspace/diagnostic request.
§Compatibility
This request was introduced in specification version 3.17.0.
sourcefn signature_help<'life0, 'async_trait>(
&'life0 self,
params: SignatureHelpParams,
) -> Pin<Box<dyn Future<Output = Result<Option<SignatureHelp>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn signature_help<'life0, 'async_trait>(
&'life0 self,
params: SignatureHelpParams,
) -> Pin<Box<dyn Future<Output = Result<Option<SignatureHelp>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/signatureHelp request is sent from the client to the server to request
signature information at a given cursor position.
sourcefn code_action<'life0, 'async_trait>(
&'life0 self,
params: CodeActionParams,
) -> Pin<Box<dyn Future<Output = Result<Option<CodeActionResponse>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn code_action<'life0, 'async_trait>(
&'life0 self,
params: CodeActionParams,
) -> Pin<Box<dyn Future<Output = Result<Option<CodeActionResponse>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/codeAction request is sent from the client to the server to compute
commands for a given text document and range. These commands are typically code fixes to
either fix problems or to beautify/refactor code.
The result of a textDocument/codeAction request is an array of Command literals which
are typically presented in the user interface.
To ensure that a server is useful in many clients, the commands specified in a code actions
should be handled by the server and not by the client (see workspace/executeCommand and
ServerCapabilities::execute_command_provider). If the client supports providing edits
with a code action, then the mode should be used.
When the command is selected the server should be contacted again (via the
workspace/executeCommand request) to execute the command.
§Compatibility
§Since version 3.16.0
A client can offer a server to delay the computation of code action properties during a
textDocument/codeAction request. This is useful for cases where it is expensive to
compute the value of a property (for example, the edit property).
Clients signal this through the code_action.resolve_support client capability which lists
all properties a client can resolve lazily. The server capability
code_action_provider.resolve_provider signals that a server will offer a
codeAction/resolve route.
To help servers uniquely identify a code action in the resolve request, a code action
literal may optionally carry a data property. This is also guarded by an additional
client capability code_action.data_support. In general, a client should offer data
support if it offers resolve support.
It should also be noted that servers shouldn’t alter existing attributes of a code action
in a codeAction/resolve request.
§Since version 3.8.0
Support for CodeAction literals to enable the following scenarios:
-
The ability to directly return a workspace edit from the code action request. This avoids having another server roundtrip to execute an actual code action. However server providers should be aware that if the code action is expensive to compute or the edits are huge it might still be beneficial if the result is simply a command and the actual edit is only computed when needed.
-
The ability to group code actions using a kind. Clients are allowed to ignore that information. However it allows them to better group code action, for example, into corresponding menus (e.g. all refactor code actions into a refactor menu).
sourcefn code_action_resolve<'life0, 'async_trait>(
&'life0 self,
params: CodeAction,
) -> Pin<Box<dyn Future<Output = Result<CodeAction>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn code_action_resolve<'life0, 'async_trait>(
&'life0 self,
params: CodeAction,
) -> Pin<Box<dyn Future<Output = Result<CodeAction>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The codeAction/resolve request is sent from the client to the server to resolve
additional information for a given code action.
This is usually used to compute the edit property of a CodeAction to avoid its
unnecessary computation during the textDocument/codeAction request.
§Compatibility
This request was introduced in specification version 3.16.0.
sourcefn document_color<'life0, 'async_trait>(
&'life0 self,
params: DocumentColorParams,
) -> Pin<Box<dyn Future<Output = Result<Vec<ColorInformation>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn document_color<'life0, 'async_trait>(
&'life0 self,
params: DocumentColorParams,
) -> Pin<Box<dyn Future<Output = Result<Vec<ColorInformation>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/documentColor request is sent from the client to the server to list
all color references found in a given text document. Along with the range, a color value in
RGB is returned.
Clients can use the result to decorate color references in an editor. For example:
- Color boxes showing the actual color next to the reference
- Show a color picker when a color reference is edited
§Compatibility
This request was introduced in specification version 3.6.0.
sourcefn color_presentation<'life0, 'async_trait>(
&'life0 self,
params: ColorPresentationParams,
) -> Pin<Box<dyn Future<Output = Result<Vec<ColorPresentation>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn color_presentation<'life0, 'async_trait>(
&'life0 self,
params: ColorPresentationParams,
) -> Pin<Box<dyn Future<Output = Result<Vec<ColorPresentation>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/colorPresentation request is sent from the client to the server to
obtain a list of presentations for a color value at a given location.
Clients can use the result to:
- Modify a color reference
- Show in a color picker and let users pick one of the presentations
§Compatibility
This request was introduced in specification version 3.6.0.
This request has no special capabilities and registration options since it is sent as a
resolve request for the textDocument/documentColor request.
sourcefn formatting<'life0, 'async_trait>(
&'life0 self,
params: DocumentFormattingParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<TextEdit>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn formatting<'life0, 'async_trait>(
&'life0 self,
params: DocumentFormattingParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<TextEdit>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/formatting request is sent from the client to the server to format a
whole document.
sourcefn range_formatting<'life0, 'async_trait>(
&'life0 self,
params: DocumentRangeFormattingParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<TextEdit>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn range_formatting<'life0, 'async_trait>(
&'life0 self,
params: DocumentRangeFormattingParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<TextEdit>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/rangeFormatting request is sent from the client to the server to
format a given range in a document.
sourcefn on_type_formatting<'life0, 'async_trait>(
&'life0 self,
params: DocumentOnTypeFormattingParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<TextEdit>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn on_type_formatting<'life0, 'async_trait>(
&'life0 self,
params: DocumentOnTypeFormattingParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<TextEdit>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/onTypeFormatting request is sent from the client to the server to
format parts of the document during typing.
sourcefn rename<'life0, 'async_trait>(
&'life0 self,
params: RenameParams,
) -> Pin<Box<dyn Future<Output = Result<Option<WorkspaceEdit>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn rename<'life0, 'async_trait>(
&'life0 self,
params: RenameParams,
) -> Pin<Box<dyn Future<Output = Result<Option<WorkspaceEdit>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/rename request is sent from the client to the server to ask the server
to compute a workspace change so that the client can perform a workspace-wide rename of a
symbol.
sourcefn prepare_rename<'life0, 'async_trait>(
&'life0 self,
params: TextDocumentPositionParams,
) -> Pin<Box<dyn Future<Output = Result<Option<PrepareRenameResponse>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn prepare_rename<'life0, 'async_trait>(
&'life0 self,
params: TextDocumentPositionParams,
) -> Pin<Box<dyn Future<Output = Result<Option<PrepareRenameResponse>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/prepareRename request is sent from the client to the server to setup
and test the validity of a rename operation at a given location.
§Compatibility
This request was introduced in specification version 3.12.0.
sourcefn linked_editing_range<'life0, 'async_trait>(
&'life0 self,
params: LinkedEditingRangeParams,
) -> Pin<Box<dyn Future<Output = Result<Option<LinkedEditingRanges>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn linked_editing_range<'life0, 'async_trait>(
&'life0 self,
params: LinkedEditingRangeParams,
) -> Pin<Box<dyn Future<Output = Result<Option<LinkedEditingRanges>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The textDocument/linkedEditingRange request is sent from the client to the server to
return for a given position in a document the range of the symbol at the position and all
ranges that have the same content.
Optionally a word pattern can be returned to describe valid contents.
A rename to one of the ranges can be applied to all other ranges if the new content is valid. If no result-specific word pattern is provided, the word pattern from the client’s language configuration is used.
§Compatibility
This request was introduced in specification version 3.16.0.
sourcefn symbol<'life0, 'async_trait>(
&'life0 self,
params: WorkspaceSymbolParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<SymbolInformation>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn symbol<'life0, 'async_trait>(
&'life0 self,
params: WorkspaceSymbolParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Vec<SymbolInformation>>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The workspace/symbol request is sent from the client to the server to list project-wide
symbols matching the given query string.
§Compatibility
Since 3.17.0, servers can also provider a handler for workspaceSymbol/resolve requests.
This allows servers to return workspace symbols without a range for a workspace/symbol
request. Clients then need to resolve the range when necessary using the
workspaceSymbol/resolve request.
Servers can only use this new model if clients advertise support for it via the
workspace.symbol.resolve_support capability.
sourcefn symbol_resolve<'life0, 'async_trait>(
&'life0 self,
params: WorkspaceSymbol,
) -> Pin<Box<dyn Future<Output = Result<WorkspaceSymbol>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn symbol_resolve<'life0, 'async_trait>(
&'life0 self,
params: WorkspaceSymbol,
) -> Pin<Box<dyn Future<Output = Result<WorkspaceSymbol>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The workspaceSymbol/resolve request is sent from the client to the server to resolve
additional information for a given workspace symbol.
See the symbol documentation for more details.
§Compatibility
This request was introduced in specification version 3.17.0.
sourcefn did_change_configuration<'life0, 'async_trait>(
&'life0 self,
params: DidChangeConfigurationParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn did_change_configuration<'life0, 'async_trait>(
&'life0 self,
params: DidChangeConfigurationParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The workspace/didChangeConfiguration notification is sent from the client to the server
to signal the change of configuration settings.
sourcefn did_change_workspace_folders<'life0, 'async_trait>(
&'life0 self,
params: DidChangeWorkspaceFoldersParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn did_change_workspace_folders<'life0, 'async_trait>(
&'life0 self,
params: DidChangeWorkspaceFoldersParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The workspace/didChangeWorkspaceFolders notification is sent from the client to the
server to inform about workspace folder configuration changes.
The notification is sent by default if both of these boolean fields were set to true in
the initialize method:
InitializeParams::capabilities::workspace::workspace_foldersInitializeResult::capabilities::workspace::workspace_folders::supported
This notification is also sent if the server has registered itself to receive this notification.
sourcefn will_create_files<'life0, 'async_trait>(
&'life0 self,
params: CreateFilesParams,
) -> Pin<Box<dyn Future<Output = Result<Option<WorkspaceEdit>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn will_create_files<'life0, 'async_trait>(
&'life0 self,
params: CreateFilesParams,
) -> Pin<Box<dyn Future<Output = Result<Option<WorkspaceEdit>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The workspace/willCreateFiles request is sent from the client to the server before
files are actually created as long as the creation is triggered from within the client.
The request can return a WorkspaceEdit which will be applied to workspace before the
files are created. Please note that clients might drop results if computing the edit took
too long or if a server constantly fails on this request. This is done to keep creates fast
and reliable.
§Compatibility
This request was introduced in specification version 3.16.0.
sourcefn did_create_files<'life0, 'async_trait>(
&'life0 self,
params: CreateFilesParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn did_create_files<'life0, 'async_trait>(
&'life0 self,
params: CreateFilesParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The workspace/didCreateFiles request is sent from the client to the server when files
were created from within the client.
sourcefn will_rename_files<'life0, 'async_trait>(
&'life0 self,
params: RenameFilesParams,
) -> Pin<Box<dyn Future<Output = Result<Option<WorkspaceEdit>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn will_rename_files<'life0, 'async_trait>(
&'life0 self,
params: RenameFilesParams,
) -> Pin<Box<dyn Future<Output = Result<Option<WorkspaceEdit>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The workspace/willRenameFiles request is sent from the client to the server before
files are actually renamed as long as the rename is triggered from within the client.
The request can return a WorkspaceEdit which will be applied to workspace before the
files are renamed. Please note that clients might drop results if computing the edit took
too long or if a server constantly fails on this request. This is done to keep creates fast
and reliable.
§Compatibility
This request was introduced in specification version 3.16.0.
sourcefn did_rename_files<'life0, 'async_trait>(
&'life0 self,
params: RenameFilesParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn did_rename_files<'life0, 'async_trait>(
&'life0 self,
params: RenameFilesParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The workspace/didRenameFiles notification is sent from the client to the server when
files were renamed from within the client.
sourcefn will_delete_files<'life0, 'async_trait>(
&'life0 self,
params: DeleteFilesParams,
) -> Pin<Box<dyn Future<Output = Result<Option<WorkspaceEdit>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn will_delete_files<'life0, 'async_trait>(
&'life0 self,
params: DeleteFilesParams,
) -> Pin<Box<dyn Future<Output = Result<Option<WorkspaceEdit>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The workspace/willDeleteFiles request is sent from the client to the server before
files are actually deleted as long as the deletion is triggered from within the client
either by a user action or by applying a workspace edit.
The request can return a WorkspaceEdit which will be applied to workspace before the
files are deleted. Please note that clients might drop results if computing the edit took
too long or if a server constantly fails on this request. This is done to keep deletions
fast and reliable.
§Compatibility
This request was introduced in specification version 3.16.0.
sourcefn did_delete_files<'life0, 'async_trait>(
&'life0 self,
params: DeleteFilesParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn did_delete_files<'life0, 'async_trait>(
&'life0 self,
params: DeleteFilesParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The workspace/didDeleteFiles notification is sent from the client to the server when
files were deleted from within the client.
sourcefn did_change_watched_files<'life0, 'async_trait>(
&'life0 self,
params: DidChangeWatchedFilesParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn did_change_watched_files<'life0, 'async_trait>(
&'life0 self,
params: DidChangeWatchedFilesParams,
) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The workspace/didChangeWatchedFiles notification is sent from the client to the server
when the client detects changes to files watched by the language client.
It is recommended that servers register for these file events using the registration
mechanism. This can be done here or in the initialized method using
Client::register_capability.
sourcefn execute_command<'life0, 'async_trait>(
&'life0 self,
params: ExecuteCommandParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Value>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
fn execute_command<'life0, 'async_trait>(
&'life0 self,
params: ExecuteCommandParams,
) -> Pin<Box<dyn Future<Output = Result<Option<Value>>> + Send + 'async_trait>>where
Self: 'async_trait,
'life0: 'async_trait,
The workspace/executeCommand request is sent from the client to the server to trigger
command execution on the server.
In most cases, the server creates a WorkspaceEdit structure and applies the changes to
the workspace using Client::apply_edit() before returning from this function.