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    /// The [`textDocument/diagnostic`] request is sent from the client to the server to ask the
845    /// server to compute the diagnostics for a given document.
846    ///
847    /// As with other pull requests, the server is asked to compute the diagnostics for the
848    /// currently synced version of the document.
849    ///
850    /// The request doesn't define its own client and server capabilities. It is only issued if a
851    /// server registers for the [`textDocument/diagnostic`] request.
852    ///
853    /// [`textDocument/diagnostic`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_diagnostic
854    ///
855    /// # Compatibility
856    ///
857    /// This request was introduced in specification version 3.17.0.
858    #[rpc(name = "textDocument/diagnostic")]
859    async fn diagnostic(
860        &self,
861        params: DocumentDiagnosticParams,
862    ) -> Result<DocumentDiagnosticReportResult> {
863        let _ = params;
864        error!("Got a textDocument/diagnostic request, but it is not implemented");
865        Err(Error::method_not_found())
866    }
867
868    /// The [`workspace/diagnostic`] request is sent from the client to the server to ask the
869    /// server to compute workspace wide diagnostics which previously where pushed from the server
870    /// to the client.
871    ///
872    /// In contrast to the [`textDocument/diagnostic`] request, the workspace request can be
873    /// long-running and is not bound to a specific workspace or document state. If the client
874    /// supports streaming for the workspace diagnostic pull, it is legal to provide a
875    /// `textDocument/diagnostic` report multiple times for the same document URI. The last one
876    /// reported will win over previous reports.
877    ///
878    /// [`textDocument/diagnostic`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_diagnostic
879    ///
880    /// If a client receives a diagnostic report for a document in a workspace diagnostic request
881    /// for which the client also issues individual document diagnostic pull requests, the client
882    /// needs to decide which diagnostics win and should be presented. In general:
883    ///
884    /// * Diagnostics for a higher document version should win over those from a lower document
885    ///   version (e.g. note that document versions are steadily increasing).
886    /// * Diagnostics from a document pull should win over diagnostics from a workspace pull.
887    ///
888    /// The request doesn't define its own client and server capabilities. It is only issued if a
889    /// server registers for the [`workspace/diagnostic`] request.
890    ///
891    /// [`workspace/diagnostic`]: https://microsoft.github.io/language-server-protocol/specification#workspace_diagnostic
892    ///
893    /// # Compatibility
894    ///
895    /// This request was introduced in specification version 3.17.0.
896    #[rpc(name = "workspace/diagnostic")]
897    async fn workspace_diagnostic(
898        &self,
899        params: WorkspaceDiagnosticParams,
900    ) -> Result<WorkspaceDiagnosticReportResult> {
901        let _ = params;
902        error!("Got a workspace/diagnostic request, but it is not implemented");
903        Err(Error::method_not_found())
904    }
905
906    /// The [`textDocument/signatureHelp`] request is sent from the client to the server to request
907    /// signature information at a given cursor position.
908    ///
909    /// [`textDocument/signatureHelp`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_signatureHelp
910    #[rpc(name = "textDocument/signatureHelp")]
911    async fn signature_help(&self, params: SignatureHelpParams) -> Result<Option<SignatureHelp>> {
912        let _ = params;
913        error!("Got a textDocument/signatureHelp request, but it is not implemented");
914        Err(Error::method_not_found())
915    }
916
917    /// The [`textDocument/codeAction`] request is sent from the client to the server to compute
918    /// commands for a given text document and range. These commands are typically code fixes to
919    /// either fix problems or to beautify/refactor code.
920    ///
921    /// The result of a [`textDocument/codeAction`] request is an array of `Command` literals which
922    /// are typically presented in the user interface.
923    ///
924    /// [`textDocument/codeAction`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_codeAction
925    ///
926    /// To ensure that a server is useful in many clients, the commands specified in a code actions
927    /// should be handled by the server and not by the client (see [`workspace/executeCommand`] and
928    /// `ServerCapabilities::execute_command_provider`). If the client supports providing edits
929    /// with a code action, then the mode should be used.
930    ///
931    /// When the command is selected the server should be contacted again (via the
932    /// [`workspace/executeCommand`] request) to execute the command.
933    ///
934    /// [`workspace/executeCommand`]: https://microsoft.github.io/language-server-protocol/specification#workspace_executeCommand
935    ///
936    /// # Compatibility
937    ///
938    /// ## Since version 3.16.0
939    ///
940    /// A client can offer a server to delay the computation of code action properties during a
941    /// `textDocument/codeAction` request. This is useful for cases where it is expensive to
942    /// compute the value of a property (for example, the `edit` property).
943    ///
944    /// Clients signal this through the `code_action.resolve_support` client capability which lists
945    /// all properties a client can resolve lazily. The server capability
946    /// `code_action_provider.resolve_provider` signals that a server will offer a
947    /// `codeAction/resolve` route.
948    ///
949    /// To help servers uniquely identify a code action in the resolve request, a code action
950    /// literal may optionally carry a `data` property. This is also guarded by an additional
951    /// client capability `code_action.data_support`. In general, a client should offer data
952    /// support if it offers resolve support.
953    ///
954    /// It should also be noted that servers shouldn’t alter existing attributes of a code action
955    /// in a `codeAction/resolve` request.
956    ///
957    /// ## Since version 3.8.0
958    ///
959    /// Support for [`CodeAction`] literals to enable the following scenarios:
960    ///
961    /// * The ability to directly return a workspace edit from the code action request.
962    ///   This avoids having another server roundtrip to execute an actual code action.
963    ///   However server providers should be aware that if the code action is expensive to compute
964    ///   or the edits are huge it might still be beneficial if the result is simply a command and
965    ///   the actual edit is only computed when needed.
966    ///
967    /// * The ability to group code actions using a kind. Clients are allowed to ignore that
968    ///   information. However it allows them to better group code action, for example, into
969    ///   corresponding menus (e.g. all refactor code actions into a refactor menu).
970    #[rpc(name = "textDocument/codeAction")]
971    async fn code_action(&self, params: CodeActionParams) -> Result<Option<CodeActionResponse>> {
972        let _ = params;
973        error!("Got a textDocument/codeAction request, but it is not implemented");
974        Err(Error::method_not_found())
975    }
976
977    /// The [`codeAction/resolve`] request is sent from the client to the server to resolve
978    /// additional information for a given code action.
979    ///
980    /// [`codeAction/resolve`]: https://microsoft.github.io/language-server-protocol/specification#codeAction_resolve
981    ///
982    /// This is usually used to compute the edit property of a [`CodeAction`] to avoid its
983    /// unnecessary computation during the [`textDocument/codeAction`](Self::code_action) request.
984    ///
985    /// # Compatibility
986    ///
987    /// This request was introduced in specification version 3.16.0.
988    #[rpc(name = "codeAction/resolve")]
989    async fn code_action_resolve(&self, params: CodeAction) -> Result<CodeAction> {
990        let _ = params;
991        error!("Got a codeAction/resolve request, but it is not implemented");
992        Err(Error::method_not_found())
993    }
994
995    /// The [`textDocument/documentColor`] request is sent from the client to the server to list
996    /// all color references found in a given text document. Along with the range, a color value in
997    /// RGB is returned.
998    ///
999    /// [`textDocument/documentColor`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_documentColor
1000    ///
1001    /// Clients can use the result to decorate color references in an editor. For example:
1002    ///
1003    /// * Color boxes showing the actual color next to the reference
1004    /// * Show a color picker when a color reference is edited
1005    ///
1006    /// # Compatibility
1007    ///
1008    /// This request was introduced in specification version 3.6.0.
1009    #[rpc(name = "textDocument/documentColor")]
1010    async fn document_color(&self, params: DocumentColorParams) -> Result<Vec<ColorInformation>> {
1011        let _ = params;
1012        error!("Got a textDocument/documentColor request, but it is not implemented");
1013        Err(Error::method_not_found())
1014    }
1015
1016    /// The [`textDocument/colorPresentation`] request is sent from the client to the server to
1017    /// obtain a list of presentations for a color value at a given location.
1018    ///
1019    /// [`textDocument/colorPresentation`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_colorPresentation
1020    ///
1021    /// Clients can use the result to:
1022    ///
1023    /// * Modify a color reference
1024    /// * Show in a color picker and let users pick one of the presentations
1025    ///
1026    /// # Compatibility
1027    ///
1028    /// This request was introduced in specification version 3.6.0.
1029    ///
1030    /// This request has no special capabilities and registration options since it is sent as a
1031    /// resolve request for the [`textDocument/documentColor`](Self::document_color) request.
1032    #[rpc(name = "textDocument/colorPresentation")]
1033    async fn color_presentation(
1034        &self,
1035        params: ColorPresentationParams,
1036    ) -> Result<Vec<ColorPresentation>> {
1037        let _ = params;
1038        error!("Got a textDocument/colorPresentation request, but it is not implemented");
1039        Err(Error::method_not_found())
1040    }
1041
1042    /// The [`textDocument/formatting`] request is sent from the client to the server to format a
1043    /// whole document.
1044    ///
1045    /// [`textDocument/formatting`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_formatting
1046    #[rpc(name = "textDocument/formatting")]
1047    async fn formatting(&self, params: DocumentFormattingParams) -> Result<Option<Vec<TextEdit>>> {
1048        let _ = params;
1049        error!("Got a textDocument/formatting request, but it is not implemented");
1050        Err(Error::method_not_found())
1051    }
1052
1053    /// The [`textDocument/rangeFormatting`] request is sent from the client to the server to
1054    /// format a given range in a document.
1055    ///
1056    /// [`textDocument/rangeFormatting`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_rangeFormatting
1057    #[rpc(name = "textDocument/rangeFormatting")]
1058    async fn range_formatting(
1059        &self,
1060        params: DocumentRangeFormattingParams,
1061    ) -> Result<Option<Vec<TextEdit>>> {
1062        let _ = params;
1063        error!("Got a textDocument/rangeFormatting request, but it is not implemented");
1064        Err(Error::method_not_found())
1065    }
1066
1067    /// The [`textDocument/onTypeFormatting`] request is sent from the client to the server to
1068    /// format parts of the document during typing.
1069    ///
1070    /// [`textDocument/onTypeFormatting`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_onTypeFormatting
1071    #[rpc(name = "textDocument/onTypeFormatting")]
1072    async fn on_type_formatting(
1073        &self,
1074        params: DocumentOnTypeFormattingParams,
1075    ) -> Result<Option<Vec<TextEdit>>> {
1076        let _ = params;
1077        error!("Got a textDocument/onTypeFormatting request, but it is not implemented");
1078        Err(Error::method_not_found())
1079    }
1080
1081    /// The [`textDocument/rename`] request is sent from the client to the server to ask the server
1082    /// to compute a workspace change so that the client can perform a workspace-wide rename of a
1083    /// symbol.
1084    ///
1085    /// [`textDocument/rename`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_rename
1086    #[rpc(name = "textDocument/rename")]
1087    async fn rename(&self, params: RenameParams) -> Result<Option<WorkspaceEdit>> {
1088        let _ = params;
1089        error!("Got a textDocument/rename request, but it is not implemented");
1090        Err(Error::method_not_found())
1091    }
1092
1093    /// The [`textDocument/prepareRename`] request is sent from the client to the server to setup
1094    /// and test the validity of a rename operation at a given location.
1095    ///
1096    /// [`textDocument/prepareRename`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_prepareRename
1097    ///
1098    /// # Compatibility
1099    ///
1100    /// This request was introduced in specification version 3.12.0.
1101    #[rpc(name = "textDocument/prepareRename")]
1102    async fn prepare_rename(
1103        &self,
1104        params: TextDocumentPositionParams,
1105    ) -> Result<Option<PrepareRenameResponse>> {
1106        let _ = params;
1107        error!("Got a textDocument/prepareRename request, but it is not implemented");
1108        Err(Error::method_not_found())
1109    }
1110
1111    /// The [`textDocument/linkedEditingRange`] request is sent from the client to the server to
1112    /// return for a given position in a document the range of the symbol at the position and all
1113    /// ranges that have the same content.
1114    ///
1115    /// [`textDocument/linkedEditingRange`]: https://microsoft.github.io/language-server-protocol/specification#textDocument_linkedEditingRange
1116    ///
1117    /// Optionally a word pattern can be returned to describe valid contents.
1118    ///
1119    /// A rename to one of the ranges can be applied to all other ranges if the new content is
1120    /// valid. If no result-specific word pattern is provided, the word pattern from the client's
1121    /// language configuration is used.
1122    ///
1123    /// # Compatibility
1124    ///
1125    /// This request was introduced in specification version 3.16.0.
1126    #[rpc(name = "textDocument/linkedEditingRange")]
1127    async fn linked_editing_range(
1128        &self,
1129        params: LinkedEditingRangeParams,
1130    ) -> Result<Option<LinkedEditingRanges>> {
1131        let _ = params;
1132        error!("Got a textDocument/linkedEditingRange request, but it is not implemented");
1133        Err(Error::method_not_found())
1134    }
1135
1136    // Workspace Features
1137
1138    /// The [`workspace/symbol`] request is sent from the client to the server to list project-wide
1139    /// symbols matching the given query string.
1140    ///
1141    /// [`workspace/symbol`]: https://microsoft.github.io/language-server-protocol/specification#workspace_symbol
1142    ///
1143    /// # Compatibility
1144    ///
1145    /// Since 3.17.0, servers can also provider a handler for [`workspaceSymbol/resolve`] requests.
1146    /// This allows servers to return workspace symbols without a range for a `workspace/symbol`
1147    /// request. Clients then need to resolve the range when necessary using the
1148    /// `workspaceSymbol/resolve` request.
1149    ///
1150    /// [`workspaceSymbol/resolve`]: Self::symbol_resolve
1151    ///
1152    /// Servers can only use this new model if clients advertise support for it via the
1153    /// `workspace.symbol.resolve_support` capability.
1154    #[rpc(name = "workspace/symbol")]
1155    async fn symbol(
1156        &self,
1157        params: WorkspaceSymbolParams,
1158    ) -> Result<Option<Vec<SymbolInformation>>> {
1159        let _ = params;
1160        error!("Got a workspace/symbol request, but it is not implemented");
1161        Err(Error::method_not_found())
1162    }
1163
1164    /// The [`workspaceSymbol/resolve`] request is sent from the client to the server to resolve
1165    /// additional information for a given workspace symbol.
1166    ///
1167    /// [`workspaceSymbol/resolve`]: https://microsoft.github.io/language-server-protocol/specification#workspace_symbolResolve
1168    ///
1169    /// See the [`symbol`](Self::symbol) documentation for more details.
1170    ///
1171    /// # Compatibility
1172    ///
1173    /// This request was introduced in specification version 3.17.0.
1174    #[rpc(name = "workspaceSymbol/resolve")]
1175    async fn symbol_resolve(&self, params: WorkspaceSymbol) -> Result<WorkspaceSymbol> {
1176        let _ = params;
1177        error!("Got a workspaceSymbol/resolve request, but it is not implemented");
1178        Err(Error::method_not_found())
1179    }
1180
1181    /// The [`workspace/didChangeConfiguration`] notification is sent from the client to the server
1182    /// to signal the change of configuration settings.
1183    ///
1184    /// [`workspace/didChangeConfiguration`]: https://microsoft.github.io/language-server-protocol/specification#workspace_didChangeConfiguration
1185    #[rpc(name = "workspace/didChangeConfiguration")]
1186    async fn did_change_configuration(&self, params: DidChangeConfigurationParams) {
1187        let _ = params;
1188        warn!("Got a workspace/didChangeConfiguration notification, but it is not implemented");
1189    }
1190
1191    /// The [`workspace/didChangeWorkspaceFolders`] notification is sent from the client to the
1192    /// server to inform about workspace folder configuration changes.
1193    ///
1194    /// [`workspace/didChangeWorkspaceFolders`]: https://microsoft.github.io/language-server-protocol/specification#workspace_didChangeWorkspaceFolders
1195    ///
1196    /// The notification is sent by default if both of these boolean fields were set to `true` in
1197    /// the [`initialize`](Self::initialize) method:
1198    ///
1199    /// * `InitializeParams::capabilities::workspace::workspace_folders`
1200    /// * `InitializeResult::capabilities::workspace::workspace_folders::supported`
1201    ///
1202    /// This notification is also sent if the server has registered itself to receive this
1203    /// notification.
1204    #[rpc(name = "workspace/didChangeWorkspaceFolders")]
1205    async fn did_change_workspace_folders(&self, params: DidChangeWorkspaceFoldersParams) {
1206        let _ = params;
1207        warn!("Got a workspace/didChangeWorkspaceFolders notification, but it is not implemented");
1208    }
1209
1210    /// The [`workspace/willCreateFiles`] request is sent from the client to the server before
1211    /// files are actually created as long as the creation is triggered from within the client.
1212    ///
1213    /// [`workspace/willCreateFiles`]: https://microsoft.github.io/language-server-protocol/specification#workspace_willCreateFiles
1214    ///
1215    /// The request can return a [`WorkspaceEdit`] which will be applied to workspace before the
1216    /// files are created. Please note that clients might drop results if computing the edit took
1217    /// too long or if a server constantly fails on this request. This is done to keep creates fast
1218    /// and reliable.
1219    ///
1220    /// # Compatibility
1221    ///
1222    /// This request was introduced in specification version 3.16.0.
1223    #[rpc(name = "workspace/willCreateFiles")]
1224    async fn will_create_files(&self, params: CreateFilesParams) -> Result<Option<WorkspaceEdit>> {
1225        let _ = params;
1226        error!("Got a workspace/willCreateFiles request, but it is not implemented");
1227        Err(Error::method_not_found())
1228    }
1229
1230    /// The [`workspace/didCreateFiles`] request is sent from the client to the server when files
1231    /// were created from within the client.
1232    ///
1233    /// [`workspace/didCreateFiles`]: https://microsoft.github.io/language-server-protocol/specification#workspace_didCreateFiles
1234    #[rpc(name = "workspace/didCreateFiles")]
1235    async fn did_create_files(&self, params: CreateFilesParams) {
1236        let _ = params;
1237        warn!("Got a workspace/didCreateFiles notification, but it is not implemented");
1238    }
1239
1240    /// The [`workspace/willRenameFiles`] request is sent from the client to the server before
1241    /// files are actually renamed as long as the rename is triggered from within the client.
1242    ///
1243    /// [`workspace/willRenameFiles`]: https://microsoft.github.io/language-server-protocol/specification#workspace_willRenameFiles
1244    ///
1245    /// The request can return a [`WorkspaceEdit`] which will be applied to workspace before the
1246    /// files are renamed. Please note that clients might drop results if computing the edit took
1247    /// too long or if a server constantly fails on this request. This is done to keep creates fast
1248    /// and reliable.
1249    ///
1250    /// # Compatibility
1251    ///
1252    /// This request was introduced in specification version 3.16.0.
1253    #[rpc(name = "workspace/willRenameFiles")]
1254    async fn will_rename_files(&self, params: RenameFilesParams) -> Result<Option<WorkspaceEdit>> {
1255        let _ = params;
1256        error!("Got a workspace/willRenameFiles request, but it is not implemented");
1257        Err(Error::method_not_found())
1258    }
1259
1260    /// The [`workspace/didRenameFiles`] notification is sent from the client to the server when
1261    /// files were renamed from within the client.
1262    ///
1263    /// [`workspace/didRenameFiles`]: https://microsoft.github.io/language-server-protocol/specification#workspace_didRenameFiles
1264    #[rpc(name = "workspace/didRenameFiles")]
1265    async fn did_rename_files(&self, params: RenameFilesParams) {
1266        let _ = params;
1267        warn!("Got a workspace/didRenameFiles notification, but it is not implemented");
1268    }
1269
1270    /// The [`workspace/willDeleteFiles`] request is sent from the client to the server before
1271    /// files are actually deleted as long as the deletion is triggered from within the client
1272    /// either by a user action or by applying a workspace edit.
1273    ///
1274    /// [`workspace/willDeleteFiles`]: https://microsoft.github.io/language-server-protocol/specification#workspace_willDeleteFiles
1275    ///
1276    /// The request can return a [`WorkspaceEdit`] which will be applied to workspace before the
1277    /// files are deleted. Please note that clients might drop results if computing the edit took
1278    /// too long or if a server constantly fails on this request. This is done to keep deletions
1279    /// fast and reliable.
1280    ///
1281    /// # Compatibility
1282    ///
1283    /// This request was introduced in specification version 3.16.0.
1284    #[rpc(name = "workspace/willDeleteFiles")]
1285    async fn will_delete_files(&self, params: DeleteFilesParams) -> Result<Option<WorkspaceEdit>> {
1286        let _ = params;
1287        error!("Got a workspace/willDeleteFiles request, but it is not implemented");
1288        Err(Error::method_not_found())
1289    }
1290
1291    /// The [`workspace/didDeleteFiles`] notification is sent from the client to the server when
1292    /// files were deleted from within the client.
1293    ///
1294    /// [`workspace/didDeleteFiles`]: https://microsoft.github.io/language-server-protocol/specification#workspace_didDeleteFiles
1295    #[rpc(name = "workspace/didDeleteFiles")]
1296    async fn did_delete_files(&self, params: DeleteFilesParams) {
1297        let _ = params;
1298        warn!("Got a workspace/didDeleteFiles notification, but it is not implemented");
1299    }
1300
1301    /// The [`workspace/didChangeWatchedFiles`] notification is sent from the client to the server
1302    /// when the client detects changes to files watched by the language client.
1303    ///
1304    /// [`workspace/didChangeWatchedFiles`]: https://microsoft.github.io/language-server-protocol/specification#workspace_didChangeWatchedFiles
1305    ///
1306    /// It is recommended that servers register for these file events using the registration
1307    /// mechanism. This can be done here or in the [`initialized`](Self::initialized) method using
1308    /// [`Client::register_capability`](crate::Client::register_capability).
1309    #[rpc(name = "workspace/didChangeWatchedFiles")]
1310    async fn did_change_watched_files(&self, params: DidChangeWatchedFilesParams) {
1311        let _ = params;
1312        warn!("Got a workspace/didChangeWatchedFiles notification, but it is not implemented");
1313    }
1314
1315    /// The [`workspace/executeCommand`] request is sent from the client to the server to trigger
1316    /// command execution on the server.
1317    ///
1318    /// [`workspace/executeCommand`]: https://microsoft.github.io/language-server-protocol/specification#workspace_executeCommand
1319    ///
1320    /// In most cases, the server creates a [`WorkspaceEdit`] structure and applies the changes to
1321    /// the workspace using `Client::apply_edit()` before returning from this function.
1322    #[rpc(name = "workspace/executeCommand")]
1323    async fn execute_command(&self, params: ExecuteCommandParams) -> Result<Option<Value>> {
1324        let _ = params;
1325        error!("Got a workspace/executeCommand request, but it is not implemented");
1326        Err(Error::method_not_found())
1327    }
1328
1329    // TODO: Add `work_done_progress_cancel()` here (since 3.15.0) when supported by `tower-lsp`.
1330    // https://github.com/ebkalderon/tower-lsp/issues/176
1331}
1332
1333fn _assert_object_safe() {
1334    fn assert_impl<T: LanguageServer>() {}
1335    assert_impl::<Box<dyn LanguageServer>>();
1336}