With the new version of rust-analyzer, we were seeing stray `WorkDoneProgress::End`
messages that create an imbalance in the `pending_diagnostic_updates` that never
resolves. This was causing the diagnostic status bar item to never update because
we wouldn't emit `DiskBasedDiagnosticsStarted` nor `DiskBasedDiagnosticsFinished`.
This commit fixes the above situation by only acknowledging progress report for tokens
that have explicitly been created via the `WorkDoneProgressCreate` request, as stated
by the protocol.
In addition to that, we are replacing the `pending_diagnostic_updates: isize` with
a `has_pending_diagnostic_updates: bool`. We added it at some point to prevent a similar
issue where we would observe begin/end reports in a seemingly random order, which would cause
us to permanently display a `checking...` message in the status bar. I believe this commit
fixes that as well because the `isize` was just a less general solution for the same
underlying issue. As the protocol states: "the token provided in the create request should
only be used once (e.g. only one begin, many report and one end notification should be sent
to it)."
We temporarily let it grow when the message size exceed the limit,
but restore the buffer's capacity shortly after. This ensures that,
for each connection in its entire lifetime, we only ever use 1MB.
The feature doesn't work yet because the JSON language server
only supports *range* formatting, not document formatting.
We need to adjust our code to inspect the server's capabilities
and send range formatting requests instead when needed.
We're going to hold off on doing this right now, because it
will create merge conflicts with the `preserve-worktrees`
branch (#525)
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
* Use fork of async-pipe library that handles closed pipes correctly.
* Clear response handlers map when terminating output task, so as
to wake any pending request futures.
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
* Make sure the fake's IO tasks are stopped
* Ensure that the fake's stdout is closed, so that the corresponding language
server's IO tasks are woken up and halted.
This allows us to drop the context *after* we ran all futures to
completion and that's crucial otherwise we'll never drop entities
and/or flush effects.
We observed a deadlock when quitting zed. The main thread was attempting
to acquire a write lock to this outbound message sender. We weren't able
to understand exactly how this occurred, but we removed the use of a
lock there, so this shouldn't happen anymore.
Co-Authored-By: Antonio Scandurra <me@as-cii.com>
Also, add completion requests to the randomized collaboration integration test,
to demonstrate that this is valid.
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
