Filter workspace discovery error notifications for standalone/detached files

[javalsai]

Checked other resources

• This is not a bug report or a question (Please use issues for those).
• I have searched existing discussions.
• I have searched existing issues.
• This cannot be implemented in rust-analyzer.
• I have added a very descriptive title to this feature request.

Feature description

This was partially talked in #525

When working with standalone files, rust-analyzer repeatedly reports a health status error when opening or saving files, or after any other major event happens:

rust-analyzer health status is [error]:
Failed to discover workspace.
Consider adding the `Cargo.toml` of the workspace to the [`linkedProjects`](https://rust-analyzer.github.io/book/configuration.html#linkedProjects) setting.

Failed to load workspaces.
Run ':RustLsp logFile' for details.
To configure or disable rust-analyzer server status notifications,
see ':h rustaceanvim.lsp.ClientOpts'.

Minimal reproduction config

-- init.lua
local lazypath = '/tmp/_lazy/lazy.nvim'

vim.g.rustaceanvim = {
  server = {
    standalone = true,
    settings = { ['rust-analyzer'] = {} },
  },
}

if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({
    'git',
    'clone',
    '--filter=blob:none',
    'https://github.com/folke/lazy.nvim.git',
    '--branch=stable',
    lazypath,
  })
end

vim.opt.rtp:prepend(lazypath)

require('lazy').setup({
  { 'mrcjkb/rustaceanvim', lazy = false },
})

nvim -u /path/to/init.lua /any/standalone.rs

This comes from experimental/serverStatus.

The error is not critical though, lsp remains usable, but this repeated notification considerably interrupts workflow.

I do not expect full diagnostics support, it's clear that rustaceanvim has partial standalone file support, but since it has some support, this notification shouldn't be surfaced and be allowed to disrupt the experience.

Workarounds

As mentioned in the original discussion, setting vim.g.rustaceanvim.server.status_notify_level = false removes such notifications, but this also hides other legitimate status messages and I don't think this would be desired.

Creating a complete cargo project would avoid this, but is impossible in some projects, and I wouldn't consider this to support standalone files.

Solutions

rust-analyzer supports detached files, but still attempts workspace discovery and reports these errors while everything still works. I manually tested with the RPC and I cannot seem to get rid of this warning, there could be an obscure setting to improve things but I didn't find anything.

I suggest filtering notifications so that, when editing a standalone file, if the status error message contains a relevant part of this error (for example, "Failed to load workspaces"), it won't get notified.

Personally, I'm not sure if I had this issue several months ago, I was unable to fix this by changing rust-analyzer versions of about a year ago, and I can't easily bisect rustaceanvim in my configuration, so I am unaware if this could have been introduced by a recent rustaceanvim change over the last months.

While this could technically be implemented in rust-analyzer, I think it's appropriate for rustaceanvim to decide if these errors should be shown to the user if it knows it is working in standalone mode.

Related Issues

• Duplicate window/showMessage notifications when workspace discovery fails rust-lang/rust-analyzer#22817: Recent and about the same warning, but tried using rust-analyzer versions after the fix and I didn't get any results. In any case, the fix aims to deduplicate consequent messages and these would keep triggering at startup and after every other warning.

[mrcjkb]

This should definitely be fixed in rust-analyzer, not in rustaceanvim.
A compromise could be to replace the notify call in server_status.lua with a notify_once call, to prevent multiple notifications with the same message from firing.
In that case, the message should include the client ID so that it doesn't get suppressed if firing for different clients.

PRs welcome 😃

[javalsai]

Thanks for the reply, seems like a reasonable compromise, I was able to easily get a patch working with like, a tiny 2 line change.

Before getting to the PR, would you want this configurable?? Some people might want repeated status notifications so I think it's reasonable to not use notify_once by default.

[mrcjkb]

would you want this configurable

I'd say yagni 😄

[javalsai]

Just to close this, #1115 greatly improved this situation.