Show placeholder while run command gets runnables from server
This PR fixes a UI annoyance in the VS Code extension when working in large codebases where rust-analyzer can take a few moments to interact with the server. Scenario:
1. Invoke "rust-analyzer: Run" from the command palette or hotkey
2. Quickly start typing to filter the list (or press Enter to accept the last runnable)
We often do this quickly from muscle memory without waiting to see the picker. The picker often takes several seconds to come up, causing us to type garbage into the currently open editor.
Fix:
Show a placeholder item before we call out to the server.
Selecting this item does nothing so if the user accidentally hits Enter nothing happens.
The list is populated and the placeholder dismissed when the actual runnables are retrieved. From here the behavior is the same as before.
editor/code: add option to suppress error notifications
Fixes https://github.com/rust-lang/rust-analyzer/issues/14193
- Added the `rust-analyzer.showRequestFailedErrorNotification` configuration option, which defaults to `true`
- If `rust-analyzer.showRequestFailedErrorNotification` is set to `true`, the current behavior is preserved.
- If `rust-analyzer.showRequestFailedErrorNotification` is set to `false`, no error toasts will be displayed for any of the failed requests caused by panics in r-a. This _only_ applies to events that are triggered "implicitly", such as `textDocument/hover`.
To test this, you can manually introduce a panic in one of the language server LSP handlers for non-command events. I added an explicit `panic!()` in the `textDocument/hover` event handler:
#### `rust-analyzer.showRequestFailedErrorNotification` set to `true` (default)
[2023-11-07 17-17-48.webm](https://github.com/rust-lang/rust-analyzer/assets/1665677/d0408ab8-79d1-42cf-a4e7-94e99d9783ec)
#### `rust-analyzer.showRequestFailedErrorNotification` set to `false`
[2023-11-07 17-16-49.webm](https://github.com/rust-lang/rust-analyzer/assets/1665677/0496d8d0-fb53-4bc6-a279-1a47f412dbdb)
minor: Make "Expand macro" command title more explicit
Closes [#15856](https://github.com/rust-lang/rust-analyzer/issues/15856).
I opted for "caret", since it's the better term (cursor is the mouse), but I'm not sure how popular it is these days.
feat: vscode: Support opening local documentation if available
This PR implements the VS code support for opening local documentation (server side support was already implemented in #14662).
[local_docs.webm](https://github.com/rust-lang/rust-analyzer/assets/9659253/715b84dd-4f14-4ba0-a904-749b847eb3d5)
Displaying local instead of web docs can have many benefits:
- the web version may have different features enabled than locally selected
- the standard library may be a different version than is available online
- the user may not be online and therefore cannot access the web documentation
- the documentation may not be available online at all, for example because it is for a new feature in a library the user is currently developing
If the documentation is not available locally, the extension still falls back to the web version.
Closes#12867.
-----
If my implementation isn't really idiomatic TypeScript: Sorry, I'm not much of a TypeScript developer. I am open to feedback, however.
Displaying local instead of web docs can have many benefits:
- the web version may have different features enabled than locally selected
- the standard library may be a different version than is available online
- the user may not be online and therefore cannot access the web documentation
- the documentation may not be available online at all, for example because it
is for a new feature in a library the user is currently developing
If the documentation is not available locally, the extension still falls back to
the web version.
Adds a Rust Analyzer configuration option to set a custom
target directory for builds. This is a workaround for Rust Analyzer
blocking debug builds while running `cargo check`. This change
should close#6007
According to the VS Code documentation, the vscode.open command opens the URL
_in the editor_ (https://code.visualstudio.com/api/references/commands).
However, in reality, it seems to do so only for file:// URLs, falling back to
other applications for other URL schemes (at least for HTTP/HTTPS).
Until now, the URL to the documentation was always HTTP based, so using the
vscode.open command was perfectly fine. However, displaying local documentation
will be supported from now on (see next commit). Local documentation is not
HTTP-based, but instead addressed via a file:// URL. The file URL would
therefore be opened in VS Code instead of in the browser — this is definitely
not what the user wants.
Therefore, the vscode.env.openExternal function is used instead, this function
never opens the URL in VS Code.
feat: add backtick to surrounding and auto-closing pairs
Makes backticks always complete as a pair and also surround the current selection, similar to double quotes. This is useful primarily in the context of markdown doc comments, but is applied globally for simplicity.
Closes https://github.com/rust-lang/rust-analyzer/issues/11381
When building the Rust compiler with `./x check` from within VS Code,
the current `rustc` problem matcher thinks that the output from that
command that looks like this:
Build completed successfully in 0:00:26
is about a problem in a file named `0` on line 00, col 26. This wouldn't
be so bad if it wasn't for that VS Code tends to get stuck on this
problem because of problems with opening the file '0'.
The rust compiler will never output problems with a line or a column
that starts with 0, so change the regexp to require lines and cols to
begin with [1-9] to fix this problem.
extend check.overrideCommand and buildScripts.overrideCommand docs
Extend check.overrideCommand and buildScripts.overrideCommand docs regarding invocation strategy and location.
However something still seems a bit odd -- the docs for `invocationStrategy`/`invocationLocation` talk about "workspaces", but the setting that controls which workspaces are considered is called `linkedProjects`. Is a project the same as a workspace here or is there some subtle difference?
Increase the buffer size for discover project command
The default value for maxBuffer is 1 MiB[1]. If the discover project command returns stdout or stderr that is greater than 1 MiB, the extension would error with "RangeError: stderr maxBuffer length exceeded".
Set the default value for maxBuffer to 10 MiB for project discovery.
[1] https://nodejs.org/api/child_process.html#child_processexeccommand-options-callback
The default value for maxBuffer is 1 MiB[1]. If the discover project
command returns stdout or stderr that is greater than 1 MiB, the
extension would error with "RangeError: stderr maxBuffer length
exceeded".
Set the default value for maxBuffer to 10 MiB for project discovery.
[1] https://nodejs.org/api/child_process.html#child_processexeccommand-options-callback
Use the warning color when rust-analyzer is stopped
If the rust-analyzer server isn't running, we can't do much. Treat this state as a warning color, so it's more obvious.
Previously, clicking 'rust-analyzer' would stop the server
entirely. This was easy to do accidentally, and then the user has to
wait for the server to start up again.
editor/code: Break down CI steps to know what is failing easily
This do the thing I mentioned in https://github.com/rust-lang/rust-analyzer/pull/15265#issuecomment-1634424385
This aims to improve CI status check more readable.
I tried to use [`jobs.<job_id>.if`](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idif) to make the configuration
more shortly once.
But it could not fire the `end-success` or `end-failure` status if some jobs in the workflow were skipped. This causes an integration problem with bors.
By their reasons, this patch still uses `jobs.<job_id>.steps[*].if`.
---
To do this change, we reorganize npm-script.
| previous | after |
|--------------------|----------------------------------------|
| `npm run lint` | `npm run lint && npm run format:check` |
| `npm run fix` | `npm run lint:fix && npm run format` |
The previous `npm run fix` sometimes does not complete fix automatically because ESLint's autofix doees not follow prettier's formatting. So we need to run `npm run lint:fix && npm run format` by this order.
To do this change, we reorganize npm-script.
| previous | after |
|--------------------|----------------------------------------|
| `npm run lint` | `npm run lint && npm run format:check` |
| `npm run fix` | `npm run lint:fix && npm run format` |
The previous `npm run fix` sometimes does not complete fix automatically
because ESLint's autofix doees not follow prettier's formatting.
So we need to run `npm run lint:fix && npm run format` by this order.
editor/code: Use `@tsconfig/strictest` to define type checking rules
Motivation
-----------
This change aims to make it easier to manage tsconfig by [``@tsconfig/strictest`](https://www.npmjs.com/package/@tsconfig/strictest)` and intend to leave to create "ideal" rules about TypeScript's type checking.
Implementation
---------------
This change removes some duplicated rules defined in ``@tsconfig/strictest`` and add disabing some strict rules that fails with the current codebase.
Motivation
-----------
This change aims to make it easier to manage tsconfig.
This intend to leave to create "ideal" rules about TypeScript's type checking.
Implementation
---------------
This change removes some duplicated rules defined in `@tsconfig/strictest` and add disabing some strict rules
that fails with the current codebase.
fix: when running the "discoverProjectCommand", use the Rust file's parent directory instead of the workspace folder
This is a quick fix to allow the `discoverProjectCommand` to run successfully when the user has a workspace that does not, e.g., have a `.buckconfig` defined.
(It's also probably _more correct_ to set the `pwd` of the command to the parent of the Rust file _anyways_ rather than relying on the workspace folders, which may be entirely unrelated.)
internal: Add config to specifiy lru capacities for all queries
Might help figuring out what queries should be limited by LRU by default, as currently we only limit `parse`, `parse_macro_expansion` and `macro_expand`.
Add Cargo-style project discovery for Buck and Bazel Users
This feature requires the user to add a command that generates a `rust-project.json` from a set of files. Project discovery can be invoked in two ways:
1. At extension activation time, which includes the generated `rust-project.json` as part of the linkedProjects argument in `InitializeParams`.
2. Through a new command titled "rust-analyzer: Add current file to workspace", which makes use of a new, rust-analyzer-specific LSP request that adds the workspace without erasing any existing workspaces. Note that there is no mechanism to _remove_ workspaces other than "quit the rust-analyzer server".
Few notes:
- I think that the command-running functionality _could_ merit being placed into its own extension (and expose it via extension contribution points) to provide build-system idiomatic progress reporting and status handling, but I haven't (yet) made an extension that does this nor does Buck expose this sort of functionality.
- This approach would _just work_ for Bazel. I'll try and get the tool that's responsible for Buck integration open-sourced soon.
- On the testing side of things, I've used this in around my employer's Buck-powered monorepo and it's a nice experience. That being said, I can't think of an open-source repository where this can be tested in public, so you might need to trust me on this one.
I'd love to get feedback on:
- Naming of LSP extensions/new commands. I'm not too pleased with how "rust-analyzer: Add current file to workspace" is named, in that it's creating a _new_ workspace. I think that this command being added should be gated on `rust-analyzer.discoverProjectCommand` on being set, so I can add this in sequent commits.
- My Typescript. It's not particularly good.
- Suggestions on handling folders with _both_ Cargo and non-Cargo build systems and if I make activation a bit better.
(I previously tried to add this functionality entirely within rust-analyzer-the-LSP server itself, but matklad was right—an extension side approach is much, much easier.)
