mirror of
https://github.com/denoland/deno
synced 2024-07-07 20:06:37 +00:00
66b66de96a
Fixes #23643.
We weren't catching the cancellation exception thrown by TSC on the JS
side, so the rust side was catching this exception and then attempting
to print out the exception via `toString`. That last bit resulted in a
cryptic `[object Object]` showing up in the logs like so:
```
Error during TS request "getCompletionEntryDetails":
[object Object]
```
I'm not 100% sure how we weren't seeing this in the past. My guess is
that #23409 and the subsequent PR to improve the exception catching and
logging surfaced this, but I'm still not quite clear on it.
My initial fix here returned `null` to rust when a server request was
cancelled, but this resulted in a deserialization error when we
attempted to deserialize that into the expected response type. So now,
as soon as the request's cancellation token signals we'll stop waiting
for a response and return an error (which will get swallowed as the LSP
request is being cancelled).
I was a bit surprised to find that [this
branch](
|
||
|---|---|---|
| .. | ||
| testing | ||
| analysis.rs | ||
| cache.rs | ||
| capabilities.rs | ||
| client.rs | ||
| code_lens.rs | ||
| completions.rs | ||
| config.rs | ||
| diagnostics.rs | ||
| documents.rs | ||
| jsr.rs | ||
| language_server.rs | ||
| logging.rs | ||
| lsp_custom.rs | ||
| mod.rs | ||
| npm.rs | ||
| parent_process_checker.rs | ||
| path_to_regex.rs | ||
| performance.rs | ||
| README.md | ||
| refactor.rs | ||
| registries.rs | ||
| repl.rs | ||
| resolver.rs | ||
| search.rs | ||
| semantic_tokens.rs | ||
| text.rs | ||
| tsc.rs | ||
| urls.rs | ||
Deno Language Server
The Deno Language Server provides a server implementation of the
Language Server Protocol
which is specifically tailored to provide a Deno view of code. It is
integrated into the command line and can be started via the lsp sub-command.
This documentation has been moved to the Deno manual.