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}