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