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