Disable diagnostics in rust-analyzer

Hi all,

I love using the LSP to get autocomplete and jump to definition and not much else. I intentionally disable the vast majority of features from Emacs eglot, however diagnostics (red / yellow squiggly lines) are pushed from the server to the client without any opt-in or opt-out possible using the LSP protocol, it's one of those weird corner cases that the spec forgot to cover. Is there a way to opt out of them using rust-analyzer specific configuration?

You can set rust-analyzer.checkOnSave to false to stop rust-analyzer from running cargo check when saving and thus avoid those diagnostics. And rust-analyzer.diagnostics.enable to disable the diagnostics built into rust-analyzer like syntax errors or mismatched argument counts.

2 Likes

fantastic, thanks for the quick reply! Where can I learn more about the configuration values and the file where this configuration goes?

User Manual lists all config options for rust-analyzer. As for where to put them, in case of vscode it would be directly in the user or workspace settings json file. For emacs it probably depends on which lsp client you are using. The lsp client is responsible for passing these config options to rust-analyzer.

1 Like

Thanks!

It's actually still a bit unclear to me what I'm supposed to do here. The example for eglot in Emacs is

(add-to-list 'eglot-server-programs
             '((rust-ts-mode rust-mode) .
               ("rust-analyzer" :initializationOptions (:check (:command "clippy")))))

which seems to roughly translate to the example

To run cargo clippy instead of cargo check, you can set "rust-analyzer.check.command": "clippy".

but I'm not entirely sure how to translate checkOnSave or diagnostics.enable into that language. Guessing but maybe (:checkOnSave "false") ("false" rather than nil) for the former and (:diagnostics (:enable "???")) for the second.

The section User Manual says

While most errors and warnings provided by rust-analyzer come from the cargo check integration, there’s a growing number of diagnostics implemented using rust-analyzer’s own analysis. Some of these diagnostics don’t respect #[allow] or \#[deny] attributes yet, but can be turned off using the rust-analyzer.diagnostics.enable, rust-analyzer.diagnostics.experimental.enable or rust-analyzer.diagnostics.disabled settings.

but doesn't say what the values should be for any of those three settings. I guess that the two enable settings are string lists of features... would an empty string suffice to have nothing enabled? I would also guess that disabled would override any values specified in enabled since they might allow wildcards.

Apologies if I'm not seeing it in the docs! These things are sometimes very easy to find only once you know what you're looking.

Aha! Nevermind, I found the default values and parameters further down the list, e.g.

rust-analyzer.diagnostics.enable (default: true)

I'll reply when I have the working eglot config. It was a boolean, not a string list. The disabled one is a list.

(use-package eglot
  :ensure nil
  :config
  (setq eglot-report-progress nil)
  (add-to-list 'eglot-stay-out-of 'flymake)
  (add-to-list 'eglot-server-programs
               '((rust-ts-mode rust-mode) .
                 ("rust-analyzer" :initializationOptions (:diagnostics (:enable "false")))))
  )

This isn't working, I'm still getting diagnostics being sent from the rust-analyzer, so I've submitted a bug report rust-analyzer.diagnostics.enabled=false does not suppress "textDocument/publishDiagnostics" · Issue #16005 · rust-lang/rust-analyzer · GitHub

the problem was that the false must be provided as :json-false not a string literal. This is my eglot config

(use-package eglot
  :ensure nil
  :config
  (setq eglot-report-progress nil
  (add-to-list 'eglot-stay-out-of 'flymake)
  (add-to-list 'eglot-server-programs
               '((rust-ts-mode rust-mode) .
                 ("rust-analyzer"
                  :initializationOptions
                  (:checkOnSave :json-false :diagnostics (:enable :json-false)))))
  )

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.