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}