rust-analyzer wants - Githubissues

The following is a small list of issues rust-analyzer would like to see fixed/implemented, I have been asked to create this issue for an upcoming VSCode meeting so that it can be tracked.

[x] https://github.com/microsoft/vscode/issues/73120 for Rust, this is one of the worst painpoints that exists in VSCode, especially since people tend to write very rich documentation, and it’s painful to scroll down to the error.
[ ] Have VSCode improve how it renders and exposes richer diagnostics. The Rust compiler (henceforth referred to as “rustc”) has incredibly nice diagnostics, but only when rendered in the terminal. rustc's diagnostics have a ton of information (something most languages do not have) and rendering these diagnostics in VSCode in a way that keeps them useful is basically impossible. It’s really common for Rust users to look at the compiler output by running their project manually in the terminal because the inline diagnostics don't show everything nicely, and more often than not, make things more confusing. (Just on Monday, November 7, one of the main people behind the diagnostics messages of rustc now commented on this matter). There are a few open issues that could make this situation better: https://github.com/microsoft/vscode/issues/54272#issuecomment-617670458 might allow rust-analyzer to render the output inside of VS Code as the Rust compiler renders diagnostics in the terminal. https://github.com/microsoft/vscode/issues/3220 and/or https://github.com/microsoft/vscode/issues/85682: would allow rust-analyzer to render rustc-like diagnostics inline (in the style of Sublime’s Phantom Text). Implementing this feature would possibly be the diagnostics endgame for rendering Rust (and Rust-style) diagnostics.
[ ] https://github.com/microsoft/vscode/issues/145377: many users of rust-analyzer would love it if the debounce time was short and snappy as if it were when rust-analyzer implemented this feature using the decorator API. While the argument for the debounce time is that it makes updates on them less confusing and distracting, a lot of people get the impression that the server/client is rather unresponsive as the updates are no longer instantaneous.
[ ] A recent issue: when rust-analyzer returns a user-facing error via the ShowMessage LSP notification, rust-analyzer tells the user to check the error logs for more information, because it’s common to have too much information inside the pop-up/toast. To make this smoother, we would love to be able to add a button to the pop-up that switches the view to rust-analyzer’s log. Unfortunately, the LSP implementation of VSCode does not permit overwriting this functionality, as its immediately handled here: https://github.com/microsoft/vscode-languageserver-node/blob/ee58574201ba76d0da63b6826262220939996399/client/src/common/client.ts#L1001-L1015 preventing overwriting the message handlers for the notification in any form.
[ ] https://github.com/microsoft/vscode/issues/155531: this is considered to be a still-unresolved issue by us, but it was locked for some reason. We feel that either VSCode has to verify the diagnostics coming from the LSP protocol and handle empty ones appropriately (whatever that my be), allow the client to somehow handle this case itself (currently the exception is thrown before the client receives the diagnostics) or the LSP has to define that error messages are not allowed to be empty. While this isn’t the biggest issue for rust-analyzer, it is legal for rustc to emit messages with no associated message. Worse, this can occur by accident on the user’s part. It is as simple as writing or emitting a compile_error!(""). rust-analyzer then immediately emits an empty diagnostic as that is what the macro states, causing diagnostics for the opened file to freeze and no longer update until that code is removed, which is not a great experience. The user expectation is that VS Code is resilient against such bugs, and to its credit, it is in nearly all cases.

microsoft / vscode

rust-analyzer wants #165810