| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Fixes the `Debug Failure` errors described in
https://github.com/denoland/deno/issues/23643#issuecomment-2094552765 .
The issue here was that we were passing diagnostic codes as strings but
TSC expects the codes to be numbers. This resulted in some quick fixes
not working (as illustrated by the test added here which fails before
this PR).
The first commit is the actual fix. The rest are just test related.
|
|
Closes #23715
|
|
|
|
Closes #23659
|
|
|
|
result upon cancellation (#23645)
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](https://github.com/nathanwhit/deno/blob/0c671c9792ac706c1ecd60f88efdc5eb8e941917/cli/lsp/tsc.rs#L1093)
actually executes sometimes, I believe due to the fact that aborting a
future may not [immediately stop its
execution](https://docs.rs/futures/latest/futures/stream/struct.AbortHandle.html#method.abort).
|
|
This reverts commit 5cae3439912ad60eb2866f3d4372a5fe4d0de957.
Caused a +3.3s regression in one of the LSP benchmarks at
deno.land/benchmarks.
|
|
|
|
Co-authored-by: David Sherret <dsherret@gmail.com>
|
|
|
|
|
|
Ref #17944, https://github.com/swc-project/swc/issues/8893
TypeScript removes the `assert` keywords in the transpile, so this PR
only works for JavaScript files
|
|
|
|
|
|
checking) (#23513)
Closes https://github.com/jsr-io/jsr/issues/322
|
|
|
|
Before this PR, there would just be an uninformative "Error occurred"
message, after this PR you'll get a stack trace in the LSP output window
like this:
```text
Error during TS request "$getSupportedCodeFixes":
Error: i threw an exception
at serverRequest (ext:deno_tsc/99_main_compiler.js:1089:11)
```
|
|
cache when file is closed (#23517)
|
|
Doesn't have a noticeable perf impact from my benchmarking, but
theoretically should be better.
|
|
|
|
|
|
(#23451)
The actual handling of `$projectChanged` is quick, but JS requests are
not. The cleared caches only get repopulated on the next actual request,
so just batch the change notification in with the next actual request.
No significant difference in benchmarks on my machine, but this speeds
up `did_change` handling and reduces our total number of JS requests (in
addition to coalescing multiple JS change notifs into one).
|
|
|
|
|
|
Going through serde_v8 is slow, so just pass the args separately.
`op_resolve` is especially hot, so any speedups are good.
|
|
|
|
|
|
|
|
This PR enables V8 code cache for ES modules and for `require` scripts
through `op_eval_context`. Code cache artifacts are transparently stored
and fetched using sqlite db and are passed to V8. `--no-code-cache` can
be used to disable.
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
Fixes #23361.
|
|
Our cjs tracking was a bit broken. It was marking stuff as esm that was
actually cjs leading to type checking errors.
|
|
I'm running into a node resolution bug in the lsp only and while
tracking it down I noticed this one.
Fixed by moving the project version out of `Documents`.
|
|
|
|
Previously we were deserializing it twice - once to `serde_json::Value`,
and then again from the `serde_json::Value` to a concrete type
|
|
Signed-off-by: Divy Srivastava <dj.srivastava23@gmail.com>
|
|
Signed-off-by: youngwendy <clonefetch@outlook.com>
|
|
Closes https://github.com/denoland/deno/issues/22113
Closes https://github.com/denoland/deno/issues/23177
Closes https://github.com/denoland/deno/issues/22883
Closes https://github.com/denoland/deno/issues/22377
|
|
|
|
Fixes the regression described in
https://github.com/denoland/deno/pull/23293#issuecomment-2049819724.
This affected jupyter notebooks, as the LSP was passing in already
denormalized specifiers, while the jupyter kernel was not. We need to
denormalize the specifiers to evict the proper keys from our caches.
|
|
Currently we evict a lot of the caches on the JS side of things on every
request, namely script versions, script file names, and compiler
settings (as of #23283, it's not quite every request but it's still
unnecessarily often).
This PR reports changes to the JS side, so that it can evict exactly the
caches that it needs too. We might want to do some batching in the
future so as not to do 1 request per change.
|
|
|
|
Previously we locked the entire `FileSystemDocuments` even for lookups,
causing contention. This was particularly bad because some of the hot
ops (namely `op_resolve`) can end up hitting that lock under contention.
This PR replaces the mutex with synchronization internal to
`FileSystemDocuments` (an `AtomicBool` for the dirty flag, and then a
`DashMap` for the actual documents).
I need to think a bit more about whether or not this introduces any
problematic race conditions.
|
|
|
|
|
|
This functionality was broken. The series of events was:
1. Load the npm resolution from the lockfile.
2. Discover only a subset of the specifiers in the documents.
3. Clear the npm snapshot.
4. Redo npm resolution with the new specifiers (~500ms).
What this now does:
1. Load the npm resolution from the lockfile.
2. Discover only a subset of the specifiers in the documents and take
into account the specifiers from the lockfile.
3. Do not redo resolution (~1ms).
|
|
|
|
|
|
Fixes #23163.
The client-facing warning doesn't provide any value and is super
annoying. We still emit a warning message on the server side for format
errors, which should fulfill the same (less intrusive) purpose.
|
|
|
