mirror of
https://github.com/astral-sh/ruff.git
synced 2025-07-07 13:15:06 +00:00
dc56c33618
Some checks are pending
CI / cargo fuzz build (push) Blocked by required conditions
CI / Determine changes (push) Waiting to run
CI / cargo fmt (push) Waiting to run
CI / cargo clippy (push) Blocked by required conditions
CI / cargo test (linux) (push) Blocked by required conditions
CI / cargo test (linux, release) (push) Blocked by required conditions
CI / cargo test (windows) (push) Blocked by required conditions
CI / cargo test (wasm) (push) Blocked by required conditions
CI / cargo build (release) (push) Waiting to run
CI / cargo build (msrv) (push) Blocked by required conditions
CI / fuzz parser (push) Blocked by required conditions
CI / test scripts (push) Blocked by required conditions
CI / ecosystem (push) Blocked by required conditions
CI / Fuzz for new ty panics (push) Blocked by required conditions
CI / cargo shear (push) Blocked by required conditions
CI / python package (push) Waiting to run
CI / pre-commit (push) Waiting to run
CI / mkdocs (push) Waiting to run
CI / formatter instabilities and black similarity (push) Blocked by required conditions
CI / test ruff-lsp (push) Blocked by required conditions
CI / check playground (push) Blocked by required conditions
CI / benchmarks-instrumented (push) Blocked by required conditions
CI / benchmarks-walltime (push) Blocked by required conditions
[ty Playground] Release / publish (push) Waiting to run
## Summary This PR adds initial support for workspace diagnostics in the ty server. Reference spec: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#workspace_diagnostic This is currently implemented via the **pull diagnostics method** which was added in the current version (3.17) and the server advertises it via the `diagnosticProvider.workspaceDiagnostics` server capability. **Note:** This might be a bit confusing but a workspace diagnostics is not for a single workspace but for all the workspaces that the server handles. These are the ones that the server received during initialization. Currently, the ty server doesn't support multiple workspaces so this capability is also limited to provide diagnostics only for a single workspace (the first one if the client provided multiple). A new `ty.diagnosticMode` server setting is added which can be either `workspace` (for workspace diagnostics) or `openFilesOnly` (for checking only open files) (default). This is same as `python.analysis.diagnosticMode` that Pyright / Pylance utilizes. In the future, we could use the value under `python.*` namespace as fallback to improve the experience on user side to avoid setting the value multiple times. Part of: astral-sh/ty#81 ## Test Plan This capability was introduced in the current LSP version (~3 years) and the way it's implemented by various clients are a bit different. I've provided notes on what I've noticed and what would need to be done on our side to further improve the experience. ### VS Code VS Code sends the `workspace/diagnostic` requests every ~2 second: ``` [Trace - 12:12:32 PM] Sending request 'workspace/diagnostic - (403)'. [Trace - 12:12:32 PM] Received response 'workspace/diagnostic - (403)' in 2ms. [Trace - 12:12:34 PM] Sending request 'workspace/diagnostic - (404)'. [Trace - 12:12:34 PM] Received response 'workspace/diagnostic - (404)' in 2ms. [Trace - 12:12:36 PM] Sending request 'workspace/diagnostic - (405)'. [Trace - 12:12:36 PM] Received response 'workspace/diagnostic - (405)' in 2ms. [Trace - 12:12:38 PM] Sending request 'workspace/diagnostic - (406)'. [Trace - 12:12:38 PM] Received response 'workspace/diagnostic - (406)' in 3ms. [Trace - 12:12:40 PM] Sending request 'workspace/diagnostic - (407)'. [Trace - 12:12:40 PM] Received response 'workspace/diagnostic - (407)' in 2ms. ... ``` I couldn't really find any resource that explains this behavior. But, this does mean that we'd need to implement the caching layer via the previous result ids sooner. This will allow the server to avoid sending all the diagnostics on every request and instead just send a response stating that the diagnostics hasn't changed yet. This could possibly be achieved by using the salsa ID. If we switch from workspace diagnostics to open-files diagnostics, the server would send the diagnostics only via the `textDocument/diagnostic` endpoint. Here, when a document containing the diagnostic is closed, the server would send a publish diagnostics notification with an empty list of diagnostics to clear the diagnostics from that document. The issue is the VS Code doesn't seem to be clearing the diagnostics in this case even though it receives the notification. (I'm going to open an issue on VS Code side for this today.) https://github.com/user-attachments/assets/b0c0833d-386c-49f5-8a15-0ac9133e15ed ### Zed Zed's implementation works by refreshing the workspace diagnostics whenever the content of the documents are changed. This seems like a very reasonable behavior and I was a bit surprised that VS Code didn't use this heuristic. https://github.com/user-attachments/assets/71c7b546-7970-434a-9ba0-4fa620647f6c ### Neovim Neovim only recently added support for workspace diagnostics (https://github.com/neovim/neovim/pull/34262, merged ~3 weeks ago) so it's only available on nightly versions. The initial support is limited and requires fetching the workspace diagnostics manually as demonstrated in the video. It doesn't support refreshing the workspace diagnostics either, so that would need to be done manually as well. I'm assuming that these are just a temporary limitation and will be implemented before the stable release. https://github.com/user-attachments/assets/25b4a0e5-9833-4877-88ad-279904fffaf9 |
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||