mirror of https://github.com/astral-sh/ruff
12 Commits
| Author | SHA1 | Message | Date |
|---|---|---|---|
Micha Reiser
|
015222900f
|
Support cancellation requests (#18627) | |
|
Micha Reiser
|
3c6c017950
|
Centralize client options validation (#18623) | |
Dhruv Manilawala
|
c2b9fa84f7
|
Refactor workspace logic into `workspace.rs` (#16295)
## Summary This is just a small refactor to move workspace related structs and impl out from `server.rs` where `Server` is defined and into a new `workspace.rs`. |
|
|
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".
(
|
|
|
Dhruv Manilawala
|
040a591cad
|
Avoid indexing the workspace for single-file mode (#13770)
## Summary This PR updates the language server to avoid indexing the workspace for single-file mode. **What's a single-file mode?** When a user opens the file directly in an editor, and not the folder that represents the workspace, the editor usually can't determine the workspace root. This means that during initializing the server, the `workspaceFolders` field will be empty / nil. Now, in this case, the server defaults to using the current working directory which is a reasonable default assuming that the directory would point to the one where this open file is present. This would allow the server to index the directory itself for any config file, if present. It turns out that in VS Code the current working directory in the above scenario is the system root directory `/` and so the server will try to index the entire root directory which would take a lot of time. This is the issue as described in https://github.com/astral-sh/ruff-vscode/issues/627. To reproduce, refer https://github.com/astral-sh/ruff-vscode/issues/627#issuecomment-2401440767. This PR updates the indexer to avoid traversing the workspace to read any config file that might be present. The first commit ( |
|
|
Dhruv Manilawala
|
0bb2fc6eec
|
Conside `include`, `extend-include` for the native server (#12252)
## Summary This PR updates the native server to consider the `include` and `extend-include` file resolver settings. fixes: #12242 ## Test Plan Note: Settings reloading doesn't work for nested configs which is fixed in #12253 so the preview here only showcases root level config. https://github.com/astral-sh/ruff/assets/67177269/e8969128-c175-4f98-8114-0d692b906cc8 |
|
Jane Lewis
|
3ab7a8da73
|
Add Jupyter Notebook document change snapshot test (#11944)
## Summary Closes #11914. This PR introduces a snapshot test that replays the LSP requests made during a document formatting request, and confirms that the notebook document is updated in the expected way. |
|
|
Jane Lewis
|
507f5c1137
|
`ruff server`: Tracing system now respects log level and trace level, with options to log to a file (#11747)
## Summary Fixes #10968. Fixes #11545. The server's tracing system has been rewritten from the ground up. The server now has trace level and log level settings which restrict the tracing events and spans that get logged. * A `logLevel` setting has been added, which lets a user set the log level. By default, it is set to `"info"`. * A `logFile` setting has also been added, which lets the user supply an optional file to send tracing output (it does not have to exist as a file yet). By default, if this is unset, tracing output will be sent to `stderr`. * A `$/setTrace` handler has also been added, and we also set the trace level from the initialization options. For editors without direct support for tracing, the environment variable `RUFF_TRACE` can override the trace level. * Small changes have been made to how we display tracing output. We no longer use `tracing-tree`, and instead use `tracing_subscriber::fmt::Layer` to format output. Thread names are now included in traces, and I've made some adjustment to thread worker names to be more useful. ## Test Plan In VS Code, with `ruff.trace.server` set to its default value, no logs from Ruff should appear. After changing `ruff.trace.server` to either `messages` or `verbose`, you should see log messages at `info` level or higher appear in Ruff's output: <img width="1005" alt="Screenshot 2024-06-10 at 10 35 04 AM" src="https://github.com/astral-sh/ruff/assets/19577865/6050d107-9815-4bd2-96d0-e86f096a57f5"> In Helix, by default, no logs from Ruff should appear. To set the trace level in Helix, you'll need to modify your language configuration as follows: ```toml [language-server.ruff] command = "/Users/jane/astral/ruff/target/debug/ruff" args = ["server", "--preview"] environment = { "RUFF_TRACE" = "messages" } ``` After doing this, logs of `info` level or higher should be visible in Helix: <img width="1216" alt="Screenshot 2024-06-10 at 10 39 26 AM" src="https://github.com/astral-sh/ruff/assets/19577865/8ff88692-d3f7-4fd1-941e-86fb338fcdcc"> You can use `:log-open` to quickly open the Helix log file. In Neovim, by default, no logs from Ruff should appear. To set the trace level in Neovim, you'll need to modify your configuration as follows: ```lua require('lspconfig').ruff.setup { cmd = {"/path/to/debug/executable", "server", "--preview"}, cmd_env = { RUFF_TRACE = "messages" } } ``` You should see logs appear in `:LspLog` that look like the following: <img width="1490" alt="Screenshot 2024-06-11 at 11 24 01 AM" src="https://github.com/astral-sh/ruff/assets/19577865/576cd5fa-03cf-477a-b879-b29a9a1200ff"> You can adjust `logLevel` and `logFile` in `settings`: ```lua require('lspconfig').ruff.setup { cmd = {"/path/to/debug/executable", "server", "--preview"}, cmd_env = { RUFF_TRACE = "messages" }, settings = { logLevel = "debug", logFile = "your/log/file/path/log.txt" } } ``` The `logLevel` and `logFile` can also be set in Helix like so: ```toml [language-server.ruff.config.settings] logLevel = "debug" logFile = "your/log/file/path/log.txt" ``` Even if this log file does not exist, it should now be created and written to after running the server: <img width="1148" alt="Screenshot 2024-06-10 at 10 43 44 AM" src="https://github.com/astral-sh/ruff/assets/19577865/ab533cf7-d5ac-4178-97f1-e56da17450dd"> |
|
|
Jane Lewis
|
b0731ef9cb
|
`ruff server`: Support Jupyter Notebook (`*.ipynb`) files (#11206)
## Summary Closes https://github.com/astral-sh/ruff/issues/10858. `ruff server` now supports `*.ipynb` (aka Jupyter Notebook) files. Extensive internal changes have been made to facilitate this, which I've done some work to contextualize with documentation and an pre-review that highlights notable sections of the code. `*.ipynb` cells should behave similarly to `*.py` documents, with one major exception. The format command `ruff.applyFormat` will only apply to the currently selected notebook cell - if you want to format an entire notebook document, use `Format Notebook` from the VS Code context menu. ## Test Plan The VS Code extension does not yet have Jupyter Notebook support enabled, so you'll first need to enable it manually. To do this, checkout the `pre-release` branch and modify `src/common/server.ts` as follows: Before:  After:  I recommend testing this PR with large, complicated notebook files. I used notebook files from [this popular repository](https://github.com/jakevdp/PythonDataScienceHandbook/tree/master/notebooks) in my preliminary testing. The main thing to test is ensuring that notebook cells behave the same as Python documents, besides the aforementioned issue with `ruff.applyFormat`. You should also test adding and deleting cells (in particular, deleting all the code cells and ensure that doesn't break anything), changing the kind of a cell (i.e. from markup -> code or vice versa), and creating a new notebook file from scratch. Finally, you should also test that source actions work as expected (and across the entire notebook). Note: `ruff.applyAutofix` and `ruff.applyOrganizeImports` are currently broken for notebook files, and I suspect it has something to do with https://github.com/astral-sh/ruff/issues/11248. Once this is fixed, I will update the test plan accordingly. --------- Co-authored-by: nolan <nolan.king90@gmail.com> |
|
|
Jane Lewis
|
2882604451
|
`ruff server`: Important errors are now shown as popups (#10951)
## Summary Fixes #10866. Introduces the `show_err_msg!` macro which will send a message to be shown as a popup to the client via the `window/showMessage` LSP method. ## Test Plan Insert various `show_err_msg!` calls in common code paths (for example, at the beginning of `event_loop`) and confirm that these messages appear in your editor. To test that panicking works correctly, add this to the top of the `fn run` definition in `crates/ruff_server/src/server/api/requests/execute_command.rs`: ```rust panic!("This should appear"); ``` Then, try running a command like `Ruff: Format document` from the command palette (`Ctrl/Cmd+Shift+P`). You should see the following messages appear:  |
|
|
Jane Lewis
|
257964a8bc
|
`ruff server` now supports `source.fixAll` source action (#10597)
## Summary `ruff server` now has source action `source.fixAll` as an available code action. This also fixes https://github.com/astral-sh/ruff/issues/10593 in the process of revising the code for quick fix code actions. ## Test Plan https://github.com/astral-sh/ruff/assets/19577865/f4c07425-e68a-445f-a4ed-949c9197a6be |
|
|
Jane Lewis
|
0c84fbb6db
|
`ruff server` - A new built-in LSP for Ruff, written in Rust (#10158)
<!-- Thank you for contributing to Ruff! To help us out with reviewing, please consider the following: - Does this pull request include a summary of the change? (See below.) - Does this pull request include a descriptive title? - Does this pull request include references to any relevant issues? --> ## Summary This PR introduces the `ruff_server` crate and a new `ruff server` command. `ruff_server` is a re-implementation of [`ruff-lsp`](https://github.com/astral-sh/ruff-lsp), written entirely in Rust. It brings significant performance improvements, much tighter integration with Ruff, a foundation for supporting entirely new language server features, and more! This PR is an early version of `ruff_lsp` that we're calling the **pre-release** version. Anyone is more than welcome to use it and submit bug reports for any issues they encounter - we'll have some documentation on how to set it up with a few common editors, and we'll also provide a pre-release VSCode extension for those interested. This pre-release version supports: - **Diagnostics for `.py` files** - **Quick fixes** - **Full-file formatting** - **Range formatting** - **Multiple workspace folders** - **Automatic linter/formatter configuration** - taken from any `pyproject.toml` files in the workspace. Many thanks to @MichaReiser for his [proof-of-concept work](https://github.com/astral-sh/ruff/pull/7262), which was important groundwork for making this PR possible. ## Architectural Decisions I've made an executive choice to go with `lsp-server` as a base framework for the LSP, in favor of `tower-lsp`. There were several reasons for this: 1. I would like to avoid `async` in our implementation. LSPs are mostly computationally bound rather than I/O bound, and `async` adds a lot of complexity to the API, while also making harder to reason about execution order. This leads into the second reason, which is... 2. Any handlers that mutate state should be blocking and run in the event loop, and the state should be lock-free. This is the approach that `rust-analyzer` uses (also with the `lsp-server`/`lsp-types` crates as a framework), and it gives us assurances about data mutation and execution order. `tower-lsp` doesn't support this, which has caused some [issues](https://github.com/ebkalderon/tower-lsp/issues/284) around data races and out-of-order handler execution. 3. In general, I think it makes sense to have tight control over scheduling and the specifics of our implementation, in exchange for a slightly higher up-front cost of writing it ourselves. We'll be able to fine-tune it to our needs and support future LSP features without depending on an upstream maintainer. ## Test Plan The pre-release of `ruff_server` will have snapshot tests for common document editing scenarios. An expanded test suite is on the roadmap for future version of `ruff_server`. |