With #15656 we started disallowing renaming of non-local items.
Although this makes sense there are some false positives that
impacted users' workflows. So this config aims to mitigate this
by giving users the liberty to disable this feature.
fix: Correct references from `rust-analyzer.cargo.check` to `rust-analyzer.check`
When reading the manual, I noticed that the documentation referenced configurations that have since been renamed. This PR updates those references to their new names.
fix: update VSCode rust-panic problem matcher
Corrected the `rust-panic` task problem matcher for the VSCode Extension to match the new panic message pattern.
From:
```
thread 'main' panicked at 'PANIC_MESSAGE', src/main.rs:L:C
```
To:
```
thread 'main' panicked at src/main.rs:L:C:
PANIC_MESSAGE
```
minor: Optimizing Performance with `Promise.all` 🏎
Hello,
This pull request introduces a modest performance improvement by executing asynchronous tasks using `Promise.all`, thereby enhancing the efficient utilization of hardware resources.
Thank you for considering this enhancement.
Ref-: https://github.com/rust-lang/rust/pull/119108
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.
