tower_lsp_f/lib.rs
1//! Language Server Protocol (LSP) server abstraction for [Tower].
2//!
3//! [Tower]: https://github.com/tower-rs/tower
4//!
5//! # Example
6//!
7//! ```rust
8//! use tower_lsp_f::jsonrpc::Result;
9//! use tower_lsp_f::lsp_types::*;
10//! use tower_lsp_f::{Client, LanguageServer, LspService, Server};
11//!
12//! #[derive(Debug)]
13//! struct Backend {
14//! client: Client,
15//! }
16//!
17//! impl LanguageServer for Backend {
18//! async fn initialize(&self, _: InitializeParams) -> Result<InitializeResult> {
19//! Ok(InitializeResult {
20//! capabilities: ServerCapabilities {
21//! hover_provider: Some(HoverProviderCapability::Simple(true)),
22//! completion_provider: Some(CompletionOptions::default()),
23//! ..Default::default()
24//! },
25//! ..Default::default()
26//! })
27//! }
28//!
29//! async fn initialized(&self, _: InitializedParams) {
30//! self.client
31//! .log_message(MessageType::INFO, "server initialized!")
32//! .await;
33//! }
34//!
35//! async fn shutdown(&self) -> Result<()> {
36//! Ok(())
37//! }
38//!
39//! async fn completion(&self, _: CompletionParams) -> Result<Option<CompletionResponse>> {
40//! Ok(Some(CompletionResponse::Array(vec![
41//! CompletionItem::new_simple("Hello".to_string(), "Some detail".to_string()),
42//! CompletionItem::new_simple("Bye".to_string(), "More detail".to_string())
43//! ])))
44//! }
45//!
46//! async fn hover(&self, _: HoverParams) -> Result<Option<Hover>> {
47//! Ok(Some(Hover {
48//! contents: HoverContents::Scalar(
49//! MarkedString::String("You're hovering!".to_string())
50//! ),
51//! range: None
52//! }))
53//! }
54//! }
55//!
56//! #[tokio::main]
57//! async fn main() {
58//! # tracing_subscriber::fmt().init();
59//! #
60//! # #[cfg(feature = "runtime-agnostic")]
61//! # use tokio_util::compat::{TokioAsyncReadCompatExt, TokioAsyncWriteCompatExt};
62//! # use std::io::Cursor;
63//! let stdin = tokio::io::stdin();
64//! let stdout = tokio::io::stdout();
65//! # let message = r#"{"jsonrpc":"2.0","method":"exit"}"#;
66//! # let (stdin, stdout) = (Cursor::new(format!("Content-Length: {}\r\n\r\n{}", message.len(), message).into_bytes()), Cursor::new(Vec::new()));
67//! # #[cfg(feature = "runtime-agnostic")]
68//! # let (stdin, stdout) = (stdin.compat(), stdout.compat_write());
69//!
70//! let (service, socket) = LspService::new(|client| Backend { client });
71//! Server::new(stdin, stdout, socket).serve(service).await;
72//! }
73//! ```
74
75#![deny(missing_debug_implementations)]
76#![deny(missing_docs)]
77#![forbid(unsafe_code)]
78
79/// A re-export of [`lsp-types`](https://docs.rs/lsp-types) for convenience.
80pub use lsp_types;
81
82pub use self::service::progress::{
83 Bounded, Cancellable, NotCancellable, OngoingProgress, Progress, Unbounded,
84};
85pub use self::service::{Client, ClientSocket, ExitedError, LspService, LspServiceBuilder};
86pub use self::transport::{Loopback, Server};
87
88use lsp_types::request::{
89 GotoDeclarationParams, GotoDeclarationResponse, GotoImplementationParams,
90 GotoImplementationResponse, GotoTypeDefinitionParams, GotoTypeDefinitionResponse,
91};
92use lsp_types::*;
93use tracing::{error, warn};
94
95use self::jsonrpc::{Error, Result};
96
97pub mod jsonrpc;
98
99mod codec;
100mod service;
101mod transport;
102
103#[macro_use]
104mod rpc;
105
106rpc! {
107/// Trait implemented by language server backends.
108///
109/// This interface allows servers adhering to the [Language Server Protocol] to be implemented in a
110/// safe and easily testable way without exposing the low-level implementation details.
111///
112/// [Language Server Protocol]: https://microsoft.github.io/language-server-protocol/
113pub trait LanguageServer: (Send + Sync + 'static) {
114 /// The [`initialize`] request is the first request sent from the client to the server.
115 ///
116 /// [`initialize`]: https://microsoft.github.io/language-server-protocol/specification#initialize
117 ///
118 /// This method is guaranteed to only execute once. If the client sends this request to the
119 /// server again, the server will respond with JSON-RPC error code `-32600` (invalid request).
120 #[rpc(name = "initialize")]
121 async fn initialize(&self, params: InitializeParams) -> Result<InitializeResult>;
122
123 /// The [`initialized`] notification is sent from the client to the server after the client
124 /// received the result of the initialize request but before the client sends anything else.
125 ///
126 /// [`initialized`]: https://microsoft.github.io/language-server-protocol/specification#initialized
127 ///
128 /// The server can use the `initialized` notification, for example, to dynamically register
129 /// capabilities with the client.
130 #[rpc(name = "initialized")]
131 async fn initialized(&self, params: InitializedParams) {
132 let _ = params;
133 }
134
135 /// The [`shutdown`] request asks the server to gracefully shut down, but to not exit.
136 ///
137 /// [`shutdown`]: https://microsoft.github.io/language-server-protocol/specification#shutdown
138 ///
139 /// This request is often later followed by an [`exit`] notification, which will cause the
140 /// server to exit immediately.
141 ///
142 /// [`exit`]: https://microsoft.github.io/language-server-protocol/specification#exit
143 ///
144 /// This method is guaranteed to only execute once. If the client sends this request to the
145 /// server again, the server will respond with JSON-RPC error code `-32600` (invalid request).
146 #[rpc(name = "shutdown")]
147 async fn shutdown(&self) -> Result<()>;
148
149 // Document Synchronization
150
151 /// The [`textDocument/didOpen`] notification is sent from the client to the server to signal
152 /// that a new text document has been opened by the client.
153 ///
154 /// [`textDocument/didOpen`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_didOpen
155 ///
156 /// The document's truth is now managed by the client and the server must not try to read the
157 /// document’s truth using the document's URI. "Open" in this sense means it is managed by the
158 /// client. It doesn't necessarily mean that its content is presented in an editor.
159 #[rpc(name = "textDocument/didOpen")]
160 async fn did_open(&self, params: DidOpenTextDocumentParams) {
161 let _ = params;
162 warn!("Got a textDocument/didOpen notification, but it is not implemented");
163 }
164
165 /// The [`textDocument/didChange`] notification is sent from the client to the server to signal
166 /// changes to a text document.
167 ///
168 /// [`textDocument/didChange`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_didChange
169 ///
170 /// This notification will contain a distinct version tag and a list of edits made to the
171 /// document for the server to interpret.
172 #[rpc(name = "textDocument/didChange")]
173 async fn did_change(&self, params: DidChangeTextDocumentParams) {
174 let _ = params;
175 warn!("Got a textDocument/didChange notification, but it is not implemented");
176 }
177
178 /// The [`textDocument/willSave`] notification is sent from the client to the server before the
179 /// document is actually saved.
180 ///
181 /// [`textDocument/willSave`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_willSave
182 #[rpc(name = "textDocument/willSave")]
183 async fn will_save(&self, params: WillSaveTextDocumentParams) {
184 let _ = params;
185 warn!("Got a textDocument/willSave notification, but it is not implemented");
186 }
187
188 /// The [`textDocument/willSaveWaitUntil`] request is sent from the client to the server before
189 /// the document is actually saved.
190 ///
191 /// [`textDocument/willSaveWaitUntil`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_willSaveWaitUntil
192 ///
193 /// The request can return an array of `TextEdit`s which will be applied to the text document
194 /// before it is saved.
195 ///
196 /// Please note that clients might drop results if computing the text edits took too long or if
197 /// a server constantly fails on this request. This is done to keep the save fast and reliable.
198 #[rpc(name = "textDocument/willSaveWaitUntil")]
199 async fn will_save_wait_until(
200 &self,
201 params: WillSaveTextDocumentParams,
202 ) -> Result<Option<Vec<TextEdit>>> {
203 let _ = params;
204 error!("Got a textDocument/willSaveWaitUntil request, but it is not implemented");
205 Err(Error::method_not_found())
206 }
207
208 /// The [`textDocument/didSave`] notification is sent from the client to the server when the
209 /// document was saved in the client.
210 ///
211 /// [`textDocument/didSave`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_didSave
212 #[rpc(name = "textDocument/didSave")]
213 async fn did_save(&self, params: DidSaveTextDocumentParams) {
214 let _ = params;
215 warn!("Got a textDocument/didSave notification, but it is not implemented");
216 }
217
218 /// The [`textDocument/didClose`] notification is sent from the client to the server when the
219 /// document got closed in the client.
220 ///
221 /// [`textDocument/didClose`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_didClose
222 ///
223 /// The document's truth now exists where the document's URI points to (e.g. if the document's
224 /// URI is a file URI, the truth now exists on disk).
225 #[rpc(name = "textDocument/didClose")]
226 async fn did_close(&self, params: DidCloseTextDocumentParams) {
227 let _ = params;
228 warn!("Got a textDocument/didClose notification, but it is not implemented");
229 }
230
231 // Language Features
232
233 /// The [`textDocument/declaration`] request asks the server for the declaration location of a
234 /// symbol at a given text document position.
235 ///
236 /// [`textDocument/declaration`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_declaration
237 ///
238 /// # Compatibility
239 ///
240 /// This request was introduced in specification version 3.14.0.
241 ///
242 /// The [`GotoDeclarationResponse::Link`](lsp_types::GotoDefinitionResponse::Link) return value
243 /// was introduced in specification version 3.14.0 and requires client-side support in order to
244 /// be used. It can be returned if the client set the following field to `true` in the
245 /// [`initialize`](Self::initialize) method:
246 ///
247 /// ```text
248 /// InitializeParams::capabilities::text_document::declaration::link_support
249 /// ```
250 #[rpc(name = "textDocument/declaration")]
251 async fn goto_declaration(
252 &self,
253 params: GotoDeclarationParams,
254 ) -> Result<Option<GotoDeclarationResponse>> {
255 let _ = params;
256 error!("Got a textDocument/declaration request, but it is not implemented");
257 Err(Error::method_not_found())
258 }
259
260 /// The [`textDocument/definition`] request asks the server for the definition location of a
261 /// symbol at a given text document position.
262 ///
263 /// [`textDocument/definition`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_definition
264 ///
265 /// # Compatibility
266 ///
267 /// The [`GotoDefinitionResponse::Link`](lsp_types::GotoDefinitionResponse::Link) return value
268 /// was introduced in specification version 3.14.0 and requires client-side support in order to
269 /// be used. It can be returned if the client set the following field to `true` in the
270 /// [`initialize`](Self::initialize) method:
271 ///
272 /// ```text
273 /// InitializeParams::capabilities::text_document::definition::link_support
274 /// ```
275 #[rpc(name = "textDocument/definition")]
276 async fn goto_definition(
277 &self,
278 params: GotoDefinitionParams,
279 ) -> Result<Option<GotoDefinitionResponse>> {
280 let _ = params;
281 error!("Got a textDocument/definition request, but it is not implemented");
282 Err(Error::method_not_found())
283 }
284
285 /// The [`textDocument/typeDefinition`] request asks the server for the type definition location of
286 /// a symbol at a given text document position.
287 ///
288 /// [`textDocument/typeDefinition`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_typeDefinition
289 ///
290 /// # Compatibility
291 ///
292 /// This request was introduced in specification version 3.6.0.
293 ///
294 /// The [`GotoTypeDefinitionResponse::Link`](lsp_types::GotoDefinitionResponse::Link) return
295 /// value was introduced in specification version 3.14.0 and requires client-side support in
296 /// order to be used. It can be returned if the client set the following field to `true` in the
297 /// [`initialize`](Self::initialize) method:
298 ///
299 /// ```text
300 /// InitializeParams::capabilities::text_document::type_definition::link_support
301 /// ```
302 #[rpc(name = "textDocument/typeDefinition")]
303 async fn goto_type_definition(
304 &self,
305 params: GotoTypeDefinitionParams,
306 ) -> Result<Option<GotoTypeDefinitionResponse>> {
307 let _ = params;
308 error!("Got a textDocument/typeDefinition request, but it is not implemented");
309 Err(Error::method_not_found())
310 }
311
312 /// The [`textDocument/implementation`] request is sent from the client to the server to resolve
313 /// the implementation location of a symbol at a given text document position.
314 ///
315 /// [`textDocument/implementation`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_implementation
316 ///
317 /// # Compatibility
318 ///
319 /// This request was introduced in specification version 3.6.0.
320 ///
321 /// The [`GotoImplementationResponse::Link`](lsp_types::GotoDefinitionResponse::Link)
322 /// return value was introduced in specification version 3.14.0 and requires client-side
323 /// support in order to be used. It can be returned if the client set the following field to
324 /// `true` in the [`initialize`](Self::initialize) method:
325 ///
326 /// ```text
327 /// InitializeParams::capabilities::text_document::implementation::link_support
328 /// ```
329 #[rpc(name = "textDocument/implementation")]
330 async fn goto_implementation(
331 &self,
332 params: GotoImplementationParams,
333 ) -> Result<Option<GotoImplementationResponse>> {
334 let _ = params;
335 error!("Got a textDocument/implementation request, but it is not implemented");
336 Err(Error::method_not_found())
337 }
338
339 /// The [`textDocument/references`] request is sent from the client to the server to resolve
340 /// project-wide references for the symbol denoted by the given text document position.
341 ///
342 /// [`textDocument/references`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_references
343 #[rpc(name = "textDocument/references")]
344 async fn references(&self, params: ReferenceParams) -> Result<Option<Vec<Location>>> {
345 let _ = params;
346 error!("Got a textDocument/references request, but it is not implemented");
347 Err(Error::method_not_found())
348 }
349
350 /// The [`textDocument/prepareCallHierarchy`] request is sent from the client to the server to
351 /// return a call hierarchy for the language element of given text document positions.
352 ///
353 /// [`textDocument/prepareCallHierarchy`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_prepareCallHierarchy
354 ///
355 /// The call hierarchy requests are executed in two steps:
356 ///
357 /// 1. First, a call hierarchy item is resolved for the given text document position (this
358 /// method).
359 /// 2. For a call hierarchy item, the incoming or outgoing call hierarchy items are resolved
360 /// inside [`incoming_calls`] and [`outgoing_calls`], respectively.
361 ///
362 /// [`incoming_calls`]: Self::incoming_calls
363 /// [`outgoing_calls`]: Self::outgoing_calls
364 ///
365 /// # Compatibility
366 ///
367 /// This request was introduced in specification version 3.16.0.
368 #[rpc(name = "textDocument/prepareCallHierarchy")]
369 async fn prepare_call_hierarchy(
370 &self,
371 params: CallHierarchyPrepareParams,
372 ) -> Result<Option<Vec<CallHierarchyItem>>> {
373 let _ = params;
374 error!("Got a textDocument/prepareCallHierarchy request, but it is not implemented");
375 Err(Error::method_not_found())
376 }
377
378 /// The [`callHierarchy/incomingCalls`] request is sent from the client to the server to
379 /// resolve **incoming** calls for a given call hierarchy item.
380 ///
381 /// The request doesn't define its own client and server capabilities. It is only issued if a
382 /// server registers for the [`textDocument/prepareCallHierarchy`] request.
383 ///
384 /// [`callHierarchy/incomingCalls`]: https://microsoft.github.io/language-server-protocol/specification#callHierarchy_incomingCalls
385 /// [`textDocument/prepareCallHierarchy`]: Self::prepare_call_hierarchy
386 ///
387 /// # Compatibility
388 ///
389 /// This request was introduced in specification version 3.16.0.
390 #[rpc(name = "callHierarchy/incomingCalls")]
391 async fn incoming_calls(
392 &self,
393 params: CallHierarchyIncomingCallsParams,
394 ) -> Result<Option<Vec<CallHierarchyIncomingCall>>> {
395 let _ = params;
396 error!("Got a callHierarchy/incomingCalls request, but it is not implemented");
397 Err(Error::method_not_found())
398 }
399
400 /// The [`callHierarchy/outgoingCalls`] request is sent from the client to the server to
401 /// resolve **outgoing** calls for a given call hierarchy item.
402 ///
403 /// The request doesn't define its own client and server capabilities. It is only issued if a
404 /// server registers for the [`textDocument/prepareCallHierarchy`] request.
405 ///
406 /// [`callHierarchy/outgoingCalls`]: https://microsoft.github.io/language-server-protocol/specification#callHierarchy_outgoingCalls
407 /// [`textDocument/prepareCallHierarchy`]: Self::prepare_call_hierarchy
408 ///
409 /// # Compatibility
410 ///
411 /// This request was introduced in specification version 3.16.0.
412 #[rpc(name = "callHierarchy/outgoingCalls")]
413 async fn outgoing_calls(
414 &self,
415 params: CallHierarchyOutgoingCallsParams,
416 ) -> Result<Option<Vec<CallHierarchyOutgoingCall>>> {
417 let _ = params;
418 error!("Got a callHierarchy/outgoingCalls request, but it is not implemented");
419 Err(Error::method_not_found())
420 }
421
422 /// The [`textDocument/prepareTypeHierarchy`] request is sent from the client to the server to
423 /// return a type hierarchy for the language element of given text document positions.
424 ///
425 /// [`textDocument/prepareTypeHierarchy`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_prepareTypeHierarchy
426 ///
427 /// Returns `Ok(None)` if the server couldn’t infer a valid type from the position.
428 ///
429 /// The type hierarchy requests are executed in two steps:
430 ///
431 /// 1. First, a type hierarchy item is prepared for the given text document position.
432 /// 2. For a type hierarchy item, the supertype or subtype type hierarchy items are resolved in
433 /// [`supertypes`](Self::supertypes) and [`subtypes`](Self::subtypes), respectively.
434 ///
435 /// # Compatibility
436 ///
437 /// This request was introduced in specification version 3.17.0.
438 #[rpc(name = "textDocument/prepareTypeHierarchy")]
439 async fn prepare_type_hierarchy(
440 &self,
441 params: TypeHierarchyPrepareParams,
442 ) -> Result<Option<Vec<TypeHierarchyItem>>> {
443 let _ = params;
444 error!("Got a textDocument/prepareTypeHierarchy request, but it is not implemented");
445 Err(Error::method_not_found())
446 }
447
448 /// The [`typeHierarchy/supertypes`] request is sent from the client to the server to resolve
449 /// the **supertypes** for a given type hierarchy item.
450 ///
451 /// Returns `Ok(None)` if the server couldn’t infer a valid type from item in `params`.
452 ///
453 /// The request doesn’t define its own client and server capabilities. It is only issued if a
454 /// server registers for the `textDocument/prepareTypeHierarchy` request.
455 ///
456 /// # Compatibility
457 ///
458 /// This request was introduced in specification version 3.17.0.
459 #[rpc(name = "typeHierarchy/supertypes")]
460 async fn supertypes(
461 &self,
462 params: TypeHierarchySupertypesParams,
463 ) -> Result<Option<Vec<TypeHierarchyItem>>> {
464 let _ = params;
465 error!("Got a typeHierarchy/supertypes request, but it is not implemented");
466 Err(Error::method_not_found())
467 }
468
469 /// The [`typeHierarchy/subtypes`] request is sent from the client to the server to resolve
470 /// the **subtypes** for a given type hierarchy item.
471 ///
472 /// Returns `Ok(None)` if the server couldn’t infer a valid type from item in `params`.
473 ///
474 /// The request doesn’t define its own client and server capabilities. It is only issued if a
475 /// server registers for the `textDocument/prepareTypeHierarchy` request.
476 ///
477 /// # Compatibility
478 ///
479 /// This request was introduced in specification version 3.17.0.
480 #[rpc(name = "typeHierarchy/subtypes")]
481 async fn subtypes(
482 &self,
483 params: TypeHierarchySubtypesParams,
484 ) -> Result<Option<Vec<TypeHierarchyItem>>> {
485 let _ = params;
486 error!("Got a typeHierarchy/subtypes request, but it is not implemented");
487 Err(Error::method_not_found())
488 }
489
490 /// The [`textDocument/documentHighlight`] request is sent from the client to the server to
491 /// resolve appropriate highlights for a given text document position.
492 ///
493 /// [`textDocument/documentHighlight`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_documentHighlight
494 ///
495 /// For programming languages, this usually highlights all textual references to the symbol
496 /// scoped to this file.
497 ///
498 /// This request differs slightly from `textDocument/references` in that this one is allowed to
499 /// be more fuzzy.
500 #[rpc(name = "textDocument/documentHighlight")]
501 async fn document_highlight(
502 &self,
503 params: DocumentHighlightParams,
504 ) -> Result<Option<Vec<DocumentHighlight>>> {
505 let _ = params;
506 error!("Got a textDocument/documentHighlight request, but it is not implemented");
507 Err(Error::method_not_found())
508 }
509
510 /// The [`textDocument/documentLink`] request is sent from the client to the server to request
511 /// the location of links in a document.
512 ///
513 /// A document link is a range in a text document that links to an internal or external
514 /// resource, like another text document or a web site.
515 ///
516 /// [`textDocument/documentLink`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_documentLink
517 ///
518 /// # Compatibility
519 ///
520 /// The [`DocumentLink::tooltip`] field was introduced in specification version 3.15.0 and
521 /// requires client-side support in order to be used. It can be returned if the client set the
522 /// following field to `true` in the [`initialize`](Self::initialize) method:
523 ///
524 /// ```text
525 /// InitializeParams::capabilities::text_document::document_link::tooltip_support
526 /// ```
527 #[rpc(name = "textDocument/documentLink")]
528 async fn document_link(&self, params: DocumentLinkParams) -> Result<Option<Vec<DocumentLink>>> {
529 let _ = params;
530 error!("Got a textDocument/documentLink request, but it is not implemented");
531 Err(Error::method_not_found())
532 }
533
534 /// The [`documentLink/resolve`] request is sent from the client to the server to resolve the
535 /// target of a given document link.
536 ///
537 /// [`documentLink/resolve`]: https://microsoft.github.io/language-server-protocol/specification#documentLink_resolve
538 ///
539 /// A document link is a range in a text document that links to an internal or external
540 /// resource, like another text document or a web site.
541 #[rpc(name = "documentLink/resolve")]
542 async fn document_link_resolve(&self, params: DocumentLink) -> Result<DocumentLink> {
543 let _ = params;
544 error!("Got a documentLink/resolve request, but it is not implemented");
545 Err(Error::method_not_found())
546 }
547
548 /// The [`textDocument/hover`] request asks the server for hover information at a given text
549 /// document position.
550 ///
551 /// [`textDocument/hover`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_hover
552 ///
553 /// Such hover information typically includes type signature information and inline
554 /// documentation for the symbol at the given text document position.
555 #[rpc(name = "textDocument/hover")]
556 async fn hover(&self, params: HoverParams) -> Result<Option<Hover>> {
557 let _ = params;
558 error!("Got a textDocument/hover request, but it is not implemented");
559 Err(Error::method_not_found())
560 }
561
562 /// The [`textDocument/codeLens`] request is sent from the client to the server to compute code
563 /// lenses for a given text document.
564 ///
565 /// [`textDocument/codeLens`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_codeLens
566 #[rpc(name = "textDocument/codeLens")]
567 async fn code_lens(&self, params: CodeLensParams) -> Result<Option<Vec<CodeLens>>> {
568 let _ = params;
569 error!("Got a textDocument/codeLens request, but it is not implemented");
570 Err(Error::method_not_found())
571 }
572
573 /// The [`codeLens/resolve`] request is sent from the client to the server to resolve the
574 /// command for a given code lens item.
575 ///
576 /// [`codeLens/resolve`]: https://microsoft.github.io/language-server-protocol/specification#codeLens_resolve
577 #[rpc(name = "codeLens/resolve")]
578 async fn code_lens_resolve(&self, params: CodeLens) -> Result<CodeLens> {
579 let _ = params;
580 error!("Got a codeLens/resolve request, but it is not implemented");
581 Err(Error::method_not_found())
582 }
583
584 /// The [`textDocument/foldingRange`] request is sent from the client to the server to return
585 /// all folding ranges found in a given text document.
586 ///
587 /// [`textDocument/foldingRange`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_foldingRange
588 ///
589 /// # Compatibility
590 ///
591 /// This request was introduced in specification version 3.10.0.
592 #[rpc(name = "textDocument/foldingRange")]
593 async fn folding_range(&self, params: FoldingRangeParams) -> Result<Option<Vec<FoldingRange>>> {
594 let _ = params;
595 error!("Got a textDocument/foldingRange request, but it is not implemented");
596 Err(Error::method_not_found())
597 }
598
599 /// The [`textDocument/selectionRange`] request is sent from the client to the server to return
600 /// suggested selection ranges at an array of given positions. A selection range is a range
601 /// around the cursor position which the user might be interested in selecting.
602 ///
603 /// [`textDocument/selectionRange`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_selectionRange
604 ///
605 /// A selection range in the return array is for the position in the provided parameters at the
606 /// same index. Therefore `params.positions[i]` must be contained in `result[i].range`.
607 ///
608 /// # Compatibility
609 ///
610 /// This request was introduced in specification version 3.15.0.
611 #[rpc(name = "textDocument/selectionRange")]
612 async fn selection_range(
613 &self,
614 params: SelectionRangeParams,
615 ) -> Result<Option<Vec<SelectionRange>>> {
616 let _ = params;
617 error!("Got a textDocument/selectionRange request, but it is not implemented");
618 Err(Error::method_not_found())
619 }
620
621 /// The [`textDocument/documentSymbol`] request is sent from the client to the server to
622 /// retrieve all symbols found in a given text document.
623 ///
624 /// [`textDocument/documentSymbol`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_documentSymbol
625 ///
626 /// The returned result is either:
627 ///
628 /// * [`DocumentSymbolResponse::Flat`] which is a flat list of all symbols found in a given
629 /// text document. Then neither the symbol’s location range nor the symbol’s container name
630 /// should be used to infer a hierarchy.
631 /// * [`DocumentSymbolResponse::Nested`] which is a hierarchy of symbols found in a given text
632 /// document.
633 #[rpc(name = "textDocument/documentSymbol")]
634 async fn document_symbol(
635 &self,
636 params: DocumentSymbolParams,
637 ) -> Result<Option<DocumentSymbolResponse>> {
638 let _ = params;
639 error!("Got a textDocument/documentSymbol request, but it is not implemented");
640 Err(Error::method_not_found())
641 }
642
643 /// The [`textDocument/semanticTokens/full`] request is sent from the client to the server to
644 /// resolve the semantic tokens of a given file.
645 ///
646 /// [`textDocument/semanticTokens/full`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_semanticTokens
647 ///
648 /// Semantic tokens are used to add additional color information to a file that depends on
649 /// language specific symbol information. A semantic token request usually produces a large
650 /// result. The protocol therefore supports encoding tokens with numbers. In addition, optional
651 /// support for deltas is available, i.e. [`semantic_tokens_full_delta`].
652 ///
653 /// [`semantic_tokens_full_delta`]: Self::semantic_tokens_full_delta
654 ///
655 /// # Compatibility
656 ///
657 /// This request was introduced in specification version 3.16.0.
658 #[rpc(name = "textDocument/semanticTokens/full")]
659 async fn semantic_tokens_full(
660 &self,
661 params: SemanticTokensParams,
662 ) -> Result<Option<SemanticTokensResult>> {
663 let _ = params;
664 error!("Got a textDocument/semanticTokens/full request, but it is not implemented");
665 Err(Error::method_not_found())
666 }
667
668 /// The [`textDocument/semanticTokens/full/delta`] request is sent from the client to the server to
669 /// resolve the semantic tokens of a given file, **returning only the delta**.
670 ///
671 /// [`textDocument/semanticTokens/full/delta`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_semanticTokens
672 ///
673 /// Similar to [`semantic_tokens_full`](Self::semantic_tokens_full), except it returns a
674 /// sequence of [`SemanticTokensEdit`] to transform a previous result into a new result.
675 ///
676 /// # Compatibility
677 ///
678 /// This request was introduced in specification version 3.16.0.
679 #[rpc(name = "textDocument/semanticTokens/full/delta")]
680 async fn semantic_tokens_full_delta(
681 &self,
682 params: SemanticTokensDeltaParams,
683 ) -> Result<Option<SemanticTokensFullDeltaResult>> {
684 let _ = params;
685 error!("Got a textDocument/semanticTokens/full/delta request, but it is not implemented");
686 Err(Error::method_not_found())
687 }
688
689 /// The [`textDocument/semanticTokens/range`] request is sent from the client to the server to
690 /// resolve the semantic tokens **for the visible range** of a given file.
691 ///
692 /// [`textDocument/semanticTokens/range`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_semanticTokens
693 ///
694 /// When a user opens a file, it can be beneficial to only compute the semantic tokens for the
695 /// visible range (faster rendering of the tokens in the user interface). If a server can
696 /// compute these tokens faster than for the whole file, it can implement this method to handle
697 /// this special case.
698 ///
699 /// See the [`semantic_tokens_full`](Self::semantic_tokens_full) documentation for more
700 /// details.
701 ///
702 /// # Compatibility
703 ///
704 /// This request was introduced in specification version 3.16.0.
705 #[rpc(name = "textDocument/semanticTokens/range")]
706 async fn semantic_tokens_range(
707 &self,
708 params: SemanticTokensRangeParams,
709 ) -> Result<Option<SemanticTokensRangeResult>> {
710 let _ = params;
711 error!("Got a textDocument/semanticTokens/range request, but it is not implemented");
712 Err(Error::method_not_found())
713 }
714
715 /// The [`textDocument/inlineValue`] request is sent from the client to the server to compute
716 /// inline values for a given text document that may be rendered in the editor at the end of
717 /// lines.
718 ///
719 /// [`textDocument/inlineValue`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_inlineValue
720 ///
721 /// # Compatibility
722 ///
723 /// This request was introduced in specification version 3.17.0.
724 #[rpc(name = "textDocument/inlineValue")]
725 async fn inline_value(&self, params: InlineValueParams) -> Result<Option<Vec<InlineValue>>> {
726 let _ = params;
727 error!("Got a textDocument/inlineValue request, but it is not implemented");
728 Err(Error::method_not_found())
729 }
730
731 /// The [`textDocument/inlayHint`] request is sent from the client to the server to compute
732 /// inlay hints for a given `(text document, range)` tuple that may be rendered in the editor
733 /// in place with other text.
734 ///
735 /// [`textDocument/inlayHint`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_inlayHint
736 ///
737 /// # Compatibility
738 ///
739 /// This request was introduced in specification version 3.17.0
740 #[rpc(name = "textDocument/inlayHint")]
741 async fn inlay_hint(&self, params: InlayHintParams) -> Result<Option<Vec<InlayHint>>> {
742 let _ = params;
743 error!("Got a textDocument/inlayHint request, but it is not implemented");
744 Err(Error::method_not_found())
745 }
746
747 /// The [`inlayHint/resolve`] request is sent from the client to the server to resolve
748 /// additional information for a given inlay hint.
749 ///
750 /// [`inlayHint/resolve`]: https://microsoft.github.io/language-server-protocol/specification#inlayHint_resolve
751 ///
752 /// This is usually used to compute the tooltip, location or command properties of an inlay
753 /// hint’s label part to avoid its unnecessary computation during the `textDocument/inlayHint`
754 /// request.
755 ///
756 /// Consider a client announces the `label.location` property as a property that can be
757 /// resolved lazily using the client capability:
758 ///
759 /// ```js
760 /// textDocument.inlayHint.resolveSupport = { properties: ['label.location'] };
761 /// ```
762 ///
763 /// then an inlay hint with a label part, but without a location, must be resolved using the
764 /// `inlayHint/resolve` request before it can be used.
765 ///
766 /// # Compatibility
767 ///
768 /// This request was introduced in specification version 3.17.0
769 #[rpc(name = "inlayHint/resolve")]
770 async fn inlay_hint_resolve(&self, params: InlayHint) -> Result<InlayHint> {
771 let _ = params;
772 error!("Got a inlayHint/resolve request, but it is not implemented");
773 Err(Error::method_not_found())
774 }
775
776 /// The [`textDocument/moniker`] request is sent from the client to the server to get the
777 /// symbol monikers for a given text document position.
778 ///
779 /// [`textDocument/moniker`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_moniker
780 ///
781 /// An array of `Moniker` types is returned as response to indicate possible monikers at the
782 /// given location. If no monikers can be calculated, `Some(vec![])` or `None` should be
783 /// returned.
784 ///
785 /// # Concept
786 ///
787 /// The Language Server Index Format (LSIF) introduced the concept of _symbol monikers_ to help
788 /// associate symbols across different indexes. This request adds capability for LSP server
789 /// implementations to provide the same symbol moniker information given a text document
790 /// position.
791 ///
792 /// Clients can utilize this method to get the moniker at the current location in a file the
793 /// user is editing and do further code navigation queries in other services that rely on LSIF
794 /// indexes and link symbols together.
795 ///
796 /// # Compatibility
797 ///
798 /// This request was introduced in specification version 3.16.0.
799 #[rpc(name = "textDocument/moniker")]
800 async fn moniker(&self, params: MonikerParams) -> Result<Option<Vec<Moniker>>> {
801 let _ = params;
802 error!("Got a textDocument/moniker request, but it is not implemented");
803 Err(Error::method_not_found())
804 }
805
806 /// The [`textDocument/completion`] request is sent from the client to the server to compute
807 /// completion items at a given cursor position.
808 ///
809 /// If computing full completion items is expensive, servers can additionally provide a handler
810 /// for the completion item resolve request (`completionItem/resolve`). This request is sent
811 /// when a completion item is selected in the user interface.
812 ///
813 /// [`textDocument/completion`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_completion
814 ///
815 /// # Compatibility
816 ///
817 /// Since 3.16.0, the client can signal that it can resolve more properties lazily. This is
818 /// done using the `completion_item.resolve_support` client capability which lists all
819 /// properties that can be filled in during a `completionItem/resolve` request.
820 ///
821 /// All other properties (usually `sort_text`, `filter_text`, `insert_text`, and `text_edit`)
822 /// must be provided in the `textDocument/completion` response and must not be changed during
823 /// resolve.
824 #[rpc(name = "textDocument/completion")]
825 async fn completion(&self, params: CompletionParams) -> Result<Option<CompletionResponse>> {
826 let _ = params;
827 error!("Got a textDocument/completion request, but it is not implemented");
828 Err(Error::method_not_found())
829 }
830
831 /// The [`completionItem/resolve`] request is sent from the client to the server to resolve
832 /// additional information for a given completion item.
833 ///
834 /// [`completionItem/resolve`]: https://microsoft.github.io/language-server-protocol/specification#completionItem_resolve
835 #[rpc(name = "completionItem/resolve")]
836 async fn completion_resolve(&self, params: CompletionItem) -> Result<CompletionItem> {
837 let _ = params;
838 error!("Got a completionItem/resolve request, but it is not implemented");
839 Err(Error::method_not_found())
840 }
841
842 /// The [`textDocument/diagnostic`] request is sent from the client to the server to ask the
843 /// server to compute the diagnostics for a given document.
844 ///
845 /// As with other pull requests, the server is asked to compute the diagnostics for the
846 /// currently synced version of the document.
847 ///
848 /// The request doesn't define its own client and server capabilities. It is only issued if a
849 /// server registers for the [`textDocument/diagnostic`] request.
850 ///
851 /// [`textDocument/diagnostic`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_diagnostic
852 ///
853 /// # Compatibility
854 ///
855 /// This request was introduced in specification version 3.17.0.
856 #[rpc(name = "textDocument/diagnostic")]
857 async fn diagnostic(
858 &self,
859 params: DocumentDiagnosticParams,
860 ) -> Result<DocumentDiagnosticReportResult> {
861 let _ = params;
862 error!("Got a textDocument/diagnostic request, but it is not implemented");
863 Err(Error::method_not_found())
864 }
865
866 /// The [`workspace/diagnostic`] request is sent from the client to the server to ask the
867 /// server to compute workspace wide diagnostics which previously where pushed from the server
868 /// to the client.
869 ///
870 /// In contrast to the [`textDocument/diagnostic`] request, the workspace request can be
871 /// long-running and is not bound to a specific workspace or document state. If the client
872 /// supports streaming for the workspace diagnostic pull, it is legal to provide a
873 /// `textDocument/diagnostic` report multiple times for the same document URI. The last one
874 /// reported will win over previous reports.
875 ///
876 /// [`textDocument/diagnostic`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_diagnostic
877 ///
878 /// If a client receives a diagnostic report for a document in a workspace diagnostic request
879 /// for which the client also issues individual document diagnostic pull requests, the client
880 /// needs to decide which diagnostics win and should be presented. In general:
881 ///
882 /// * Diagnostics for a higher document version should win over those from a lower document
883 /// version (e.g. note that document versions are steadily increasing).
884 /// * Diagnostics from a document pull should win over diagnostics from a workspace pull.
885 ///
886 /// The request doesn't define its own client and server capabilities. It is only issued if a
887 /// server registers for the [`workspace/diagnostic`] request.
888 ///
889 /// [`workspace/diagnostic`]: https://microsoft.github.io/language-server-protocol/specification#workspace_diagnostic
890 ///
891 /// # Compatibility
892 ///
893 /// This request was introduced in specification version 3.17.0.
894 #[rpc(name = "workspace/diagnostic")]
895 async fn workspace_diagnostic(
896 &self,
897 params: WorkspaceDiagnosticParams,
898 ) -> Result<WorkspaceDiagnosticReportResult> {
899 let _ = params;
900 error!("Got a workspace/diagnostic request, but it is not implemented");
901 Err(Error::method_not_found())
902 }
903
904 /// The [`textDocument/signatureHelp`] request is sent from the client to the server to request
905 /// signature information at a given cursor position.
906 ///
907 /// [`textDocument/signatureHelp`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_signatureHelp
908 #[rpc(name = "textDocument/signatureHelp")]
909 async fn signature_help(&self, params: SignatureHelpParams) -> Result<Option<SignatureHelp>> {
910 let _ = params;
911 error!("Got a textDocument/signatureHelp request, but it is not implemented");
912 Err(Error::method_not_found())
913 }
914
915 /// The [`textDocument/codeAction`] request is sent from the client to the server to compute
916 /// commands for a given text document and range. These commands are typically code fixes to
917 /// either fix problems or to beautify/refactor code.
918 ///
919 /// The result of a [`textDocument/codeAction`] request is an array of `Command` literals which
920 /// are typically presented in the user interface.
921 ///
922 /// [`textDocument/codeAction`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_codeAction
923 ///
924 /// To ensure that a server is useful in many clients, the commands specified in a code actions
925 /// should be handled by the server and not by the client (see [`workspace/executeCommand`] and
926 /// `ServerCapabilities::execute_command_provider`). If the client supports providing edits
927 /// with a code action, then the mode should be used.
928 ///
929 /// When the command is selected the server should be contacted again (via the
930 /// [`workspace/executeCommand`] request) to execute the command.
931 ///
932 /// [`workspace/executeCommand`]: https://microsoft.github.io/language-server-protocol/specification#workspace_executeCommand
933 ///
934 /// # Compatibility
935 ///
936 /// ## Since version 3.16.0
937 ///
938 /// A client can offer a server to delay the computation of code action properties during a
939 /// `textDocument/codeAction` request. This is useful for cases where it is expensive to
940 /// compute the value of a property (for example, the `edit` property).
941 ///
942 /// Clients signal this through the `code_action.resolve_support` client capability which lists
943 /// all properties a client can resolve lazily. The server capability
944 /// `code_action_provider.resolve_provider` signals that a server will offer a
945 /// `codeAction/resolve` route.
946 ///
947 /// To help servers uniquely identify a code action in the resolve request, a code action
948 /// literal may optionally carry a `data` property. This is also guarded by an additional
949 /// client capability `code_action.data_support`. In general, a client should offer data
950 /// support if it offers resolve support.
951 ///
952 /// It should also be noted that servers shouldn’t alter existing attributes of a code action
953 /// in a `codeAction/resolve` request.
954 ///
955 /// ## Since version 3.8.0
956 ///
957 /// Support for [`CodeAction`] literals to enable the following scenarios:
958 ///
959 /// * The ability to directly return a workspace edit from the code action request.
960 /// This avoids having another server roundtrip to execute an actual code action.
961 /// However server providers should be aware that if the code action is expensive to compute
962 /// or the edits are huge it might still be beneficial if the result is simply a command and
963 /// the actual edit is only computed when needed.
964 ///
965 /// * The ability to group code actions using a kind. Clients are allowed to ignore that
966 /// information. However it allows them to better group code action, for example, into
967 /// corresponding menus (e.g. all refactor code actions into a refactor menu).
968 #[rpc(name = "textDocument/codeAction")]
969 async fn code_action(&self, params: CodeActionParams) -> Result<Option<CodeActionResponse>> {
970 let _ = params;
971 error!("Got a textDocument/codeAction request, but it is not implemented");
972 Err(Error::method_not_found())
973 }
974
975 /// The [`codeAction/resolve`] request is sent from the client to the server to resolve
976 /// additional information for a given code action.
977 ///
978 /// [`codeAction/resolve`]: https://microsoft.github.io/language-server-protocol/specification#codeAction_resolve
979 ///
980 /// This is usually used to compute the edit property of a [`CodeAction`] to avoid its
981 /// unnecessary computation during the [`textDocument/codeAction`](Self::code_action) request.
982 ///
983 /// # Compatibility
984 ///
985 /// This request was introduced in specification version 3.16.0.
986 #[rpc(name = "codeAction/resolve")]
987 async fn code_action_resolve(&self, params: CodeAction) -> Result<CodeAction> {
988 let _ = params;
989 error!("Got a codeAction/resolve request, but it is not implemented");
990 Err(Error::method_not_found())
991 }
992
993 /// The [`textDocument/documentColor`] request is sent from the client to the server to list
994 /// all color references found in a given text document. Along with the range, a color value in
995 /// RGB is returned.
996 ///
997 /// [`textDocument/documentColor`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_documentColor
998 ///
999 /// Clients can use the result to decorate color references in an editor. For example:
1000 ///
1001 /// * Color boxes showing the actual color next to the reference
1002 /// * Show a color picker when a color reference is edited
1003 ///
1004 /// # Compatibility
1005 ///
1006 /// This request was introduced in specification version 3.6.0.
1007 #[rpc(name = "textDocument/documentColor")]
1008 async fn document_color(&self, params: DocumentColorParams) -> Result<Vec<ColorInformation>> {
1009 let _ = params;
1010 error!("Got a textDocument/documentColor request, but it is not implemented");
1011 Err(Error::method_not_found())
1012 }
1013
1014 /// The [`textDocument/colorPresentation`] request is sent from the client to the server to
1015 /// obtain a list of presentations for a color value at a given location.
1016 ///
1017 /// [`textDocument/colorPresentation`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_colorPresentation
1018 ///
1019 /// Clients can use the result to:
1020 ///
1021 /// * Modify a color reference
1022 /// * Show in a color picker and let users pick one of the presentations
1023 ///
1024 /// # Compatibility
1025 ///
1026 /// This request was introduced in specification version 3.6.0.
1027 ///
1028 /// This request has no special capabilities and registration options since it is sent as a
1029 /// resolve request for the [`textDocument/documentColor`](Self::document_color) request.
1030 #[rpc(name = "textDocument/colorPresentation")]
1031 async fn color_presentation(
1032 &self,
1033 params: ColorPresentationParams,
1034 ) -> Result<Vec<ColorPresentation>> {
1035 let _ = params;
1036 error!("Got a textDocument/colorPresentation request, but it is not implemented");
1037 Err(Error::method_not_found())
1038 }
1039
1040 /// The [`textDocument/formatting`] request is sent from the client to the server to format a
1041 /// whole document.
1042 ///
1043 /// [`textDocument/formatting`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_formatting
1044 #[rpc(name = "textDocument/formatting")]
1045 async fn formatting(&self, params: DocumentFormattingParams) -> Result<Option<Vec<TextEdit>>> {
1046 let _ = params;
1047 error!("Got a textDocument/formatting request, but it is not implemented");
1048 Err(Error::method_not_found())
1049 }
1050
1051 /// The [`textDocument/rangeFormatting`] request is sent from the client to the server to
1052 /// format a given range in a document.
1053 ///
1054 /// [`textDocument/rangeFormatting`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_rangeFormatting
1055 #[rpc(name = "textDocument/rangeFormatting")]
1056 async fn range_formatting(
1057 &self,
1058 params: DocumentRangeFormattingParams,
1059 ) -> Result<Option<Vec<TextEdit>>> {
1060 let _ = params;
1061 error!("Got a textDocument/rangeFormatting request, but it is not implemented");
1062 Err(Error::method_not_found())
1063 }
1064
1065 /// The [`textDocument/onTypeFormatting`] request is sent from the client to the server to
1066 /// format parts of the document during typing.
1067 ///
1068 /// [`textDocument/onTypeFormatting`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_onTypeFormatting
1069 #[rpc(name = "textDocument/onTypeFormatting")]
1070 async fn on_type_formatting(
1071 &self,
1072 params: DocumentOnTypeFormattingParams,
1073 ) -> Result<Option<Vec<TextEdit>>> {
1074 let _ = params;
1075 error!("Got a textDocument/onTypeFormatting request, but it is not implemented");
1076 Err(Error::method_not_found())
1077 }
1078
1079 /// The [`textDocument/rename`] request is sent from the client to the server to ask the server
1080 /// to compute a workspace change so that the client can perform a workspace-wide rename of a
1081 /// symbol.
1082 ///
1083 /// [`textDocument/rename`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_rename
1084 #[rpc(name = "textDocument/rename")]
1085 async fn rename(&self, params: RenameParams) -> Result<Option<WorkspaceEdit>> {
1086 let _ = params;
1087 error!("Got a textDocument/rename request, but it is not implemented");
1088 Err(Error::method_not_found())
1089 }
1090
1091 /// The [`textDocument/prepareRename`] request is sent from the client to the server to setup
1092 /// and test the validity of a rename operation at a given location.
1093 ///
1094 /// [`textDocument/prepareRename`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_prepareRename
1095 ///
1096 /// # Compatibility
1097 ///
1098 /// This request was introduced in specification version 3.12.0.
1099 #[rpc(name = "textDocument/prepareRename")]
1100 async fn prepare_rename(
1101 &self,
1102 params: TextDocumentPositionParams,
1103 ) -> Result<Option<PrepareRenameResponse>> {
1104 let _ = params;
1105 error!("Got a textDocument/prepareRename request, but it is not implemented");
1106 Err(Error::method_not_found())
1107 }
1108
1109 /// The [`textDocument/linkedEditingRange`] request is sent from the client to the server to
1110 /// return for a given position in a document the range of the symbol at the position and all
1111 /// ranges that have the same content.
1112 ///
1113 /// [`textDocument/linkedEditingRange`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_linkedEditingRange
1114 ///
1115 /// Optionally a word pattern can be returned to describe valid contents.
1116 ///
1117 /// A rename to one of the ranges can be applied to all other ranges if the new content is
1118 /// valid. If no result-specific word pattern is provided, the word pattern from the client's
1119 /// language configuration is used.
1120 ///
1121 /// # Compatibility
1122 ///
1123 /// This request was introduced in specification version 3.16.0.
1124 #[rpc(name = "textDocument/linkedEditingRange")]
1125 async fn linked_editing_range(
1126 &self,
1127 params: LinkedEditingRangeParams,
1128 ) -> Result<Option<LinkedEditingRanges>> {
1129 let _ = params;
1130 error!("Got a textDocument/linkedEditingRange request, but it is not implemented");
1131 Err(Error::method_not_found())
1132 }
1133
1134 // Workspace Features
1135
1136 /// The [`workspace/symbol`] request is sent from the client to the server to list project-wide
1137 /// symbols matching the given query string.
1138 ///
1139 /// [`workspace/symbol`]: https://microsoft.github.io/language-server-protocol/specification#workspace_symbol
1140 ///
1141 /// # Compatibility
1142 ///
1143 /// Since 3.17.0, servers can also provider a handler for [`workspaceSymbol/resolve`] requests.
1144 /// This allows servers to return workspace symbols without a range for a `workspace/symbol`
1145 /// request. Clients then need to resolve the range when necessary using the
1146 /// `workspaceSymbol/resolve` request.
1147 ///
1148 /// [`workspaceSymbol/resolve`]: Self::symbol_resolve
1149 ///
1150 /// Servers can only use this new model if clients advertise support for it via the
1151 /// `workspace.symbol.resolve_support` capability.
1152 #[rpc(name = "workspace/symbol")]
1153 async fn symbol(
1154 &self,
1155 params: WorkspaceSymbolParams,
1156 ) -> Result<Option<Vec<SymbolInformation>>> {
1157 let _ = params;
1158 error!("Got a workspace/symbol request, but it is not implemented");
1159 Err(Error::method_not_found())
1160 }
1161
1162 /// The [`workspaceSymbol/resolve`] request is sent from the client to the server to resolve
1163 /// additional information for a given workspace symbol.
1164 ///
1165 /// [`workspaceSymbol/resolve`]: https://microsoft.github.io/language-server-protocol/specification#workspace_symbolResolve
1166 ///
1167 /// See the [`symbol`](Self::symbol) documentation for more details.
1168 ///
1169 /// # Compatibility
1170 ///
1171 /// This request was introduced in specification version 3.17.0.
1172 #[rpc(name = "workspaceSymbol/resolve")]
1173 async fn symbol_resolve(&self, params: WorkspaceSymbol) -> Result<WorkspaceSymbol> {
1174 let _ = params;
1175 error!("Got a workspaceSymbol/resolve request, but it is not implemented");
1176 Err(Error::method_not_found())
1177 }
1178
1179 /// The [`workspace/didChangeConfiguration`] notification is sent from the client to the server
1180 /// to signal the change of configuration settings.
1181 ///
1182 /// [`workspace/didChangeConfiguration`]: https://microsoft.github.io/language-server-protocol/specification#workspace_didChangeConfiguration
1183 #[rpc(name = "workspace/didChangeConfiguration")]
1184 async fn did_change_configuration(&self, params: DidChangeConfigurationParams) {
1185 let _ = params;
1186 warn!("Got a workspace/didChangeConfiguration notification, but it is not implemented");
1187 }
1188
1189 /// The [`workspace/didChangeWorkspaceFolders`] notification is sent from the client to the
1190 /// server to inform about workspace folder configuration changes.
1191 ///
1192 /// [`workspace/didChangeWorkspaceFolders`]: https://microsoft.github.io/language-server-protocol/specification#workspace_didChangeWorkspaceFolders
1193 ///
1194 /// The notification is sent by default if both of these boolean fields were set to `true` in
1195 /// the [`initialize`](Self::initialize) method:
1196 ///
1197 /// * `InitializeParams::capabilities::workspace::workspace_folders`
1198 /// * `InitializeResult::capabilities::workspace::workspace_folders::supported`
1199 ///
1200 /// This notification is also sent if the server has registered itself to receive this
1201 /// notification.
1202 #[rpc(name = "workspace/didChangeWorkspaceFolders")]
1203 async fn did_change_workspace_folders(&self, params: DidChangeWorkspaceFoldersParams) {
1204 let _ = params;
1205 warn!("Got a workspace/didChangeWorkspaceFolders notification, but it is not implemented");
1206 }
1207
1208 /// The [`workspace/willCreateFiles`] request is sent from the client to the server before
1209 /// files are actually created as long as the creation is triggered from within the client.
1210 ///
1211 /// [`workspace/willCreateFiles`]: https://microsoft.github.io/language-server-protocol/specification#workspace_willCreateFiles
1212 ///
1213 /// The request can return a [`WorkspaceEdit`] which will be applied to workspace before the
1214 /// files are created. Please note that clients might drop results if computing the edit took
1215 /// too long or if a server constantly fails on this request. This is done to keep creates fast
1216 /// and reliable.
1217 ///
1218 /// # Compatibility
1219 ///
1220 /// This request was introduced in specification version 3.16.0.
1221 #[rpc(name = "workspace/willCreateFiles")]
1222 async fn will_create_files(&self, params: CreateFilesParams) -> Result<Option<WorkspaceEdit>> {
1223 let _ = params;
1224 error!("Got a workspace/willCreateFiles request, but it is not implemented");
1225 Err(Error::method_not_found())
1226 }
1227
1228 /// The [`workspace/didCreateFiles`] request is sent from the client to the server when files
1229 /// were created from within the client.
1230 ///
1231 /// [`workspace/didCreateFiles`]: https://microsoft.github.io/language-server-protocol/specification#workspace_didCreateFiles
1232 #[rpc(name = "workspace/didCreateFiles")]
1233 async fn did_create_files(&self, params: CreateFilesParams) {
1234 let _ = params;
1235 warn!("Got a workspace/didCreateFiles notification, but it is not implemented");
1236 }
1237
1238 /// The [`workspace/willRenameFiles`] request is sent from the client to the server before
1239 /// files are actually renamed as long as the rename is triggered from within the client.
1240 ///
1241 /// [`workspace/willRenameFiles`]: https://microsoft.github.io/language-server-protocol/specification#workspace_willRenameFiles
1242 ///
1243 /// The request can return a [`WorkspaceEdit`] which will be applied to workspace before the
1244 /// files are renamed. Please note that clients might drop results if computing the edit took
1245 /// too long or if a server constantly fails on this request. This is done to keep creates fast
1246 /// and reliable.
1247 ///
1248 /// # Compatibility
1249 ///
1250 /// This request was introduced in specification version 3.16.0.
1251 #[rpc(name = "workspace/willRenameFiles")]
1252 async fn will_rename_files(&self, params: RenameFilesParams) -> Result<Option<WorkspaceEdit>> {
1253 let _ = params;
1254 error!("Got a workspace/willRenameFiles request, but it is not implemented");
1255 Err(Error::method_not_found())
1256 }
1257
1258 /// The [`workspace/didRenameFiles`] notification is sent from the client to the server when
1259 /// files were renamed from within the client.
1260 ///
1261 /// [`workspace/didRenameFiles`]: https://microsoft.github.io/language-server-protocol/specification#workspace_didRenameFiles
1262 #[rpc(name = "workspace/didRenameFiles")]
1263 async fn did_rename_files(&self, params: RenameFilesParams) {
1264 let _ = params;
1265 warn!("Got a workspace/didRenameFiles notification, but it is not implemented");
1266 }
1267
1268 /// The [`workspace/willDeleteFiles`] request is sent from the client to the server before
1269 /// files are actually deleted as long as the deletion is triggered from within the client
1270 /// either by a user action or by applying a workspace edit.
1271 ///
1272 /// [`workspace/willDeleteFiles`]: https://microsoft.github.io/language-server-protocol/specification#workspace_willDeleteFiles
1273 ///
1274 /// The request can return a [`WorkspaceEdit`] which will be applied to workspace before the
1275 /// files are deleted. Please note that clients might drop results if computing the edit took
1276 /// too long or if a server constantly fails on this request. This is done to keep deletions
1277 /// fast and reliable.
1278 ///
1279 /// # Compatibility
1280 ///
1281 /// This request was introduced in specification version 3.16.0.
1282 #[rpc(name = "workspace/willDeleteFiles")]
1283 async fn will_delete_files(&self, params: DeleteFilesParams) -> Result<Option<WorkspaceEdit>> {
1284 let _ = params;
1285 error!("Got a workspace/willDeleteFiles request, but it is not implemented");
1286 Err(Error::method_not_found())
1287 }
1288
1289 /// The [`workspace/didDeleteFiles`] notification is sent from the client to the server when
1290 /// files were deleted from within the client.
1291 ///
1292 /// [`workspace/didDeleteFiles`]: https://microsoft.github.io/language-server-protocol/specification#workspace_didDeleteFiles
1293 #[rpc(name = "workspace/didDeleteFiles")]
1294 async fn did_delete_files(&self, params: DeleteFilesParams) {
1295 let _ = params;
1296 warn!("Got a workspace/didDeleteFiles notification, but it is not implemented");
1297 }
1298
1299 /// The [`workspace/didChangeWatchedFiles`] notification is sent from the client to the server
1300 /// when the client detects changes to files watched by the language client.
1301 ///
1302 /// [`workspace/didChangeWatchedFiles`]: https://microsoft.github.io/language-server-protocol/specification#workspace_didChangeWatchedFiles
1303 ///
1304 /// It is recommended that servers register for these file events using the registration
1305 /// mechanism. This can be done here or in the [`initialized`](Self::initialized) method using
1306 /// [`Client::register_capability`](crate::Client::register_capability).
1307 #[rpc(name = "workspace/didChangeWatchedFiles")]
1308 async fn did_change_watched_files(&self, params: DidChangeWatchedFilesParams) {
1309 let _ = params;
1310 warn!("Got a workspace/didChangeWatchedFiles notification, but it is not implemented");
1311 }
1312
1313 /// The [`workspace/executeCommand`] request is sent from the client to the server to trigger
1314 /// command execution on the server.
1315 ///
1316 /// [`workspace/executeCommand`]: https://microsoft.github.io/language-server-protocol/specification#workspace_executeCommand
1317 ///
1318 /// In most cases, the server creates a [`WorkspaceEdit`] structure and applies the changes to
1319 /// the workspace using `Client::apply_edit()` before returning from this function.
1320 #[rpc(name = "workspace/executeCommand")]
1321 async fn execute_command(&self, params: ExecuteCommandParams) -> Result<Option<LSPAny>> {
1322 let _ = params;
1323 error!("Got a workspace/executeCommand request, but it is not implemented");
1324 Err(Error::method_not_found())
1325 }
1326
1327 // TODO: Add `work_done_progress_cancel()` here (since 3.15.0) when supported by `tower-lsp`.
1328 // https://github.com/ebkalderon/tower-lsp/issues/176
1329}
1330}