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