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