mirror of
https://github.com/astral-sh/ruff.git
synced 2025-10-29 03:02:27 +00:00
7 commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Micha Reiser
|
b51c4f82ea
|
Rename Red Knot (#17820) | ||
|
Nuri Jung
|
58807b2980
|
Server: Use min instead of max to limit the number of threads (#17421)
## Summary Prevent overcommit by using max 4 threads as intended. Unintuitively, `.max()` returns the maximum value of `self` and the argument (not limiting to the argument). To limit the value to 4, one needs to use `.min()`. https://doc.rust-lang.org/std/cmp/trait.Ord.html#method.max |
||
|
Micha Reiser
|
67f8c30b53
|
[red-knot] Remove global dead_code from red-knot-server (#17229)
## Summary Use more local `expect(dead_code)` suppressions instead of a global `allow(dead_code)` in `lib.rs`. Remove some methods that are either easy to add later, are less likely to be needed for red knot, or it's unclear if we'd add it the same way as in ruff. |
||
|
Micha Reiser
|
2ae39edccf
|
[red-knot] Goto type definition (#16901)
## Summary Implement basic *Goto type definition* support for Red Knot's LSP. This PR also builds the foundation for other LSP operations. E.g., Goto definition, hover, etc., should be able to reuse some, if not most, logic introduced in this PR. The basic steps of resolving the type definitions are: 1. Find the closest token for the cursor offset. This is a bit more subtle than I first anticipated because the cursor could be positioned right between the callee and the `(` in `call(test)`, in which case we want to resolve the type for `call`. 2. Find the node with the minimal range that fully encloses the token found in 1. I somewhat suspect that 1 and 2 could be done at the same time but it complicated things because we also need to compute the spine (ancestor chain) for the node and there's no guarantee that the found nodes have the same ancestors 3. Reduce the node found in 2. to a node that is a valid goto target. This may require traversing upwards to e.g. find the closest expression. 4. Resolve the type for the goto target 5. Resolve the location for the type, return it to the LSP ## Design decisions The current implementation navigates to the inferred type. I think this is what we want because it means that it correctly accounts for narrowing (in which case we want to go to the narrowed type because that's the value's type at the given position). However, it does have the downside that Goto type definition doesn't work whenever we infer `T & Unknown` because intersection types aren't supported. I'm not sure what to do about this specific case, other than maybe ignoring `Unkown` in Goto type definition if the type is an intersection? ## Known limitations * Types defined in the vendored typeshed aren't supported because the client can't open files from the red knot binary (we can either implement our own file protocol and handler OR extract the typeshed files and point there). See https://github.com/astral-sh/ruff/issues/17041 * Red Knot only exposes an API to get types for expressions and definitions. However, there are many other nodes with identifiers that can have a type (e.g. go to type of a globals statement, match patterns, ...). We can add support for those in separate PRs (after we figure out how to query the types from the semantic model). See https://github.com/astral-sh/ruff/issues/17113 * We should have a higher-level API for the LSP that doesn't directly call semantic queries. I intentionally decided not to design that API just yet. ## Test plan https://github.com/user-attachments/assets/fa077297-a42d-4ec8-b71f-90c0802b4edb Goto type definition on a union <img width="1215" alt="Screenshot 2025-04-01 at 13 02 55" src="https://github.com/user-attachments/assets/689cabcc-4a86-4a18-b14a-c56f56868085" /> Note: I recorded this using a custom typeshed path so that navigating to builtins works. |
||
|
Dhruv Manilawala
|
1447553bc2
|
Improve logging system using logLevel, avoid trace value (#15232)
## Summary
Refer to the VS Code PR
(https://github.com/astral-sh/ruff-vscode/pull/659) for details on the
change.
This PR changes the following:
1. Add tracing span for both request (request id and method name) and
notification (method name) handler
2. Remove the `RUFF_TRACE` environment variable. This was being used to
turn on / off logging for the server
3. Similarly, remove reading the `trace` value from the initialization
options
4. Remove handling the `$/setTrace` notification
5. Remove the specialized `TraceLogWriter` used for Zed and VS Code
(https://github.com/astral-sh/ruff/pull/12564)
Regarding the (5) for the Zed editor, the reason that was implemented
was because there was no way of looking at the stderr messages in the
editor which has been changed. Now, it captures the stderr as part of
the "Server Logs".
(
|
||
|
Micha Reiser
|
df7345e118
|
Exit with an error if there are check failures (#12735) | ||
|
Dhruv Manilawala
|
e91a0fe94a
|
[red-knot] Implement basic LSP server (#12624)
## Summary This PR adds basic LSP implementation for the Red Knot project. This is basically a fork of the existing `ruff_server` crate into a `red_knot_server` crate. The following are the main differences: 1. The `Session` stores a map from workspace root to the corresponding Red Knot database (`RootDatabase`). 2. The database is initialized with the newly implemented `LSPSystem` (implementation of `System` trait) 3. The `LSPSystem` contains the server index corresponding to each workspace and an underlying OS system implementation. For certain methods, the system first checks if there's an open document in LSP system and returns the information from that. Otherwise, it falls back to the OS system to get that information. These methods are `path_metadata`, `read_to_string` and `read_to_notebook` 4. Add `as_any_mut` method for `System` **Why fork?** Forking allows us to experiment with the functionalities that are specific to Red Knot. The architecture is completely different and so the requirements for an LSP implementation are different as well. For example, Red Knot only supports a single workspace, so the LSP system needs to map the multi-workspace support to each Red Knot instance. In the end, the server code isn't too big, it will be easier to implement Red Knot specific functionality without worrying about existing server limitations and it shouldn't be difficult to port the existing server. ## Review Most of the server files hasn't been changed. I'm going to list down the files that have been changed along with highlight the specific part of the file that's changed from the existing server code. Changed files: * Red Knot CLI implementation: https://github.com/astral-sh/ruff/pull/12624/files#diff-579596339a29d3212a641232e674778c339b446de33b890c7fdad905b5eb50e1 * In https://github.com/astral-sh/ruff/pull/12624/files#diff-b9a9041a8a2bace014bf3687c3ef0512f25e0541f112fad6131b14242f408db6, server capabilities have been updated, dynamic capability registration is removed * In https://github.com/astral-sh/ruff/pull/12624/files#diff-b9a9041a8a2bace014bf3687c3ef0512f25e0541f112fad6131b14242f408db6, the API for `clear_diagnostics` now take in a `Url` instead of `DocumentQuery` as the document version doesn't matter when clearing diagnostics after a document is closed * [`did_close`](https://github.com/astral-sh/ruff/pull/12624/files#diff-9271370102a6f3be8defaca40c82485b0048731942520b491a3bdd2ee0e25493), [`did_close_notebook`](https://github.com/astral-sh/ruff/pull/12624/files#diff-96fb53ffb12c1694356e17313e4bb37b3f0931e887878b5d7c896c19ff60283b), [`did_open`](https://github.com/astral-sh/ruff/pull/12624/files#diff-60e852cf1aa771e993131cabf98eb4c467963a8328f10eccdb43b3e8f0f1fb12), [`did_open_notebook`](https://github.com/astral-sh/ruff/pull/12624/files#diff-ac356eb5e36c3b2c1c135eda9dfbcab5c12574d1cb77c71f7da8dbcfcfb2d2f1) are updated to open / close file from the corresponding Red Knot workspace * The [diagnostic handler](https://github.com/astral-sh/ruff/pull/12624/files#diff-4475f318fd0290d0292834569a7df5699debdcc0a453b411b8c3d329f1b879d9) is updated to request diagnostics from Red Knot * The [`Session::new`] method in https://github.com/astral-sh/ruff/pull/12624/files#diff-55c96201296200c1cab37c8b0407b6c733381374b94be7ae50563bfe95264e4d is updated to construct the Red Knot databases for each workspace. It also contains the `index_mut` and `MutIndexGuard` implementation * And, `LSPSystem` implementation is in https://github.com/astral-sh/ruff/pull/12624/files#diff-4ed62bd359c43b0bf1a13f04349dcd954966934bb8d544de7813f974182b489e ## Test Plan First, configure VS Code to use the `red_knot` binary 1. Build the `red_knot` binary by `cargo build` 2. Update the VS Code extension to specify the path to this binary ```json { "ruff.path": ["/path/to/ruff/target/debug/red_knot"] } ``` 3. Restart VS Code Now, open a file containing red-knot specific diagnostics, close the file and validate that diagnostics disappear. |