I’ll try my best to nudge this back on rails again. Seems this issue is a real hot potato 🫤

@dzdrav We all love Rust Analyzer and are grateful for the work done on it, this issue is self-evident that fact; we put up with something that really bothers us because the tool is so important and wonderful. I know this issue is frustrating, but your first post reads as entitled and derogatory, intended or not.

But tone aside… @dzdrav does also hit the nail on the head.

If there is an option to disable popups, then what happens when they’re enabled would be another discussion.

R-A devs… that’s the underlying theme and frustration with this issue and all the others like it. It’s the same message I’ve repeated over, and over, and over again. I’m asking that an option to be added to disable all error toasts, nothing else. Everything else (telemetry, bug-fixes, filtering, et. al) is out of scope and shouldn’t hold up this issue. They are all important, but they are all out of scope.

---

$50 Bounty

I’m charging tactic… who ever gets this issue fixed and deployed, gets a Venmo/Zelle transfer from me, for $50 USD. If anyone else wants to chip in a bounty I’m sure that will speed up the process.

@jprochazk Done Thank you so much, you’ve made at least one developer incredibly happy ❤️

@AThilenius

kafkaesk situation

I have decided the only real workaround is either sticky notes, or this:

(Double right-click on a relaxing video in Youtube and click on picture-in-picture)

Alright, I did a second pass through things, with #14901 there are only 2 cases where the server itself sends a error/warning pop up request:

• if the server is a dev built or profiling is enabled, overly long loop turns and server panics are reported as pop ups.
• the client does not support the experimental status notification (the status icon in the bottom bar in vscode)

But there is actually a third error pop up that can occur, that is not from a request of the server to the client, but instead when the server responds to a client request with an error (as is the case for panics). VSCode screams at the user in this case that a request has failed, I’ll look into whether thats configurable/hookable on the client code but if not I would consider that a VSCode “feature” or whatever since that handling is out of our hands (and I refuse to add a flag to make the server not report errors to the client, raise that problem upstream on the VSCode repo then). Assuming Do not disturb mode does not make VSCode ignore LSP request errors, I’d consider that part a VSCode bug.

We agree that normal cargo check errors shouldn’t cause an error notification. That argument is what’s actually off-topic, because if you read the original issue it’s about whether crashes should cause an error notification.

Quoting the original comment:

Feature request: Add an option to suppress all Rust Analyzer errors from bubbling up to VSCode toasts.

If there is an option to disable popups, then what happens when they’re enabled would be another discussion. The main point of Do Not Disturb mode is to avoid disturbances such as those.

@dzdrav I think the problem isn’t that we’re all idiots who don’t want to improve UX, but that there’s only a small amount of contributors. I like @OmarTawfik’s idea, but e.g. I don’t know how to start implementing this. On the same vein, maybe someone can guide you to implement this.

That was not my aim to imply, but the main impression from the discussion was the adament stance to “decide which popups to show” or “fix the reason” some of them are showing, which just goes around the issue of having a toggle for them.

I would be happy to take a look if you could guide me to the relevant code (and if we agree that it could be configurable as an option).

@AThilenius Thanks for writing this up!

Adding one more use case:

I work on a monorepo of tens of crates that use build.rs to edit other crates before building as well, relying on Cargo incrementability. When developing/editing these build scripts, fly-check will often run them, and possibly produce intermediate/broken output, which fails loading other crates downstream.

This makes the notification boxes (and the distraction they cause) almost constant for us.

While adding a button to the error toasts to suppress further ones for the session sounds okay

cc @Veykril, if I may suggest, I want to think about how we can eliminate notification boxes all together, instead of trying to figure out how to show it less frequently. Notifications should be reserved for:

1. One-time questions, like a consent form, or a pending update.
2. In response to direct user interactions.

Workspace loading, build scripts, and fly-check issues should not be triggering notifications IMO, given how distracting they are. I wonder if we can use the vscode.languages.createLanguageStatusItem() API, replacing both notification boxes, and the current status bar item.

LanguageStatusItem A language status item is the preferred way to present language status reports for the active text editors, such as selected linter or notifying about a configuration problem. https://code.visualstudio.com/api/references/vscode-api#LanguageStatusItem

IIUC, this also has the following additional benefits:

1. It can be resolved automatically, once the next fly check is triggered, and the issue is cleared.
2. It has a document selector, so it is hidden when users navigate away from rust files, unlike the current status bar item.
3. It can have multiple actions/buttons, instead of the single click event for the the current status bar item to stop/restart the server.

Completely agree, these should be displayed as some kind of persistent error state instead of a notification.

@flodiebold Thing is, we already have this feature: I can get full information just by hovering over that button in VSCode.

But in addition to that, I also get this: Notice how it overlaps my project explorer, stealing screen space as the errors pile up.

I can reproduce this issue by renaming a lib.rs to anything_else.rs in a multi-crate workspace.

I seem to be getting these 2 error notifications when moving/renaming source files and saving Cargo.toml mid-edit:

rust-analyzer failed to load workspace: Failed to read Cargo metadata from Cargo.toml file...

Followed by:

cargo check failed

Any edits which invalidate the cargo seem to cause these notifications. Why should these be reported to user as error notifications? I know the cargo is invalid, I’m in the process of fixing it.

Completely agree, these should be displayed as some kind of persistent error state instead of a notification.

@AThilenius have you actually reported your crash? I know you’re saying this issue isn’t about that, but before you start claiming that it’s impossible to address your annoyance by just fixing the crashes, you could at least try; otherwise it’s just a self-fulfilling prophecy.

I think everyone here fully understands that the correct reaction to these errors is fixing them. This isn’t about fixing rust-analyzer errors. This is about using telemetry to report these errors directly to people who are better equipped to do something about it, instead of passing it to the user and hoping they do that manually or try and fix it themselves.

Most people would simply dismiss these errors since it’s very difficult (at least for me) to shift one’s focus from solving a complicated programming problem to debugging rust-analyzer. So more often than not, the error message just serves to annoy the user and not provide any actual value.