GNU bug report logs - #78862
31.0.50; Eglot couldn't refresh Flymake diagnostics on Rust project

Previous Next

Full log

Message #23 received at 78862 <at> debbugs.gnu.org (full text, mbox):

From: matthewktromp <at> gmail.com
To: Eason Huang <aqua0210 <at> foxmail.com>, Eli Zaretskii <eliz <at> gnu.org>,
 Spencer Baugh <sbaugh <at> janestreet.com>,  João Távora
 <joaotavora <at> gmail.com>
Cc: 78862 <at> debbugs.gnu.org
Subject: Re: bug#78862: 31.0.50; Eglot couldn't refresh Flymake diagnostics
 on Rust project
Date: Wed, 23 Jul 2025 12:53:27 -0400

[Message part 1 (text/plain, inline)]

I ran a git bisect and found that commit
0ff82eb48725e15bb87a75d4f937b75c2482c59b appears to be the first commit
to exhibit this behavior, although I'm not entirely sure why.  It was a
fix for bug #69809.

My understanding is this: every time flymake recomputes diagnostics
(e.g. on file save), it queries all of the backends in
`flymake-diagnostic-functions' to get new diagnostics.  When it gets new
diagnostics from a backend, it goes through the buffer, removes all the
existing diagnostics produced by that backend, and inserts the new
diagnostics that it just got.

Before running eglot, `flymake-diagnostic-functions' is equal to
(rust-ts-flymake t) (I'm not sure what the significance of the t is).

When you start eglot, this line in `eglot--managed-mode' replaces the
value of flymake-diagnostic-functions:
(eglot--setq-saving flymake-diagnostic-functions '(eglot-flymake-backend))
Then it has flymake refresh its diagnostics.  Since rust-ts-flymake is
no longer in flymake-diagnostic-functions, flymake doesn't request any
new diagnostics from it.  But since flymake only deletes the existing
overlays for a diagnostics backend when that backend provides new
diagnostics, those diagnostics never get removed.

The attached patch fixes this by adding code to flymake-start which goes
through flymake--state and removes all diagnostics and their overlays
from any backend which is no longer in flymake-diagnostic-functions.

I also noticed a related (but less serious) bug here: after opening a
rust buffer, running rust-ts-mode, then eglot, if you stop eglot with
eglot-shutdown or something, all the eglot diagnostics in the buffer are
removed, but the rust-ts-flymake diagnostics don't come back until you
do something to trigger flymake-start (like save the buffer).

Eason Huang <aqua0210 <at> foxmail.com> writes:

> I find out that it is related to `rust-ts-flymake-command`, when
> customize it's value to `'("cargo" "clippy")`, it works as expected.
>
> It works with below rust config:
>
> ```
> (use-package rust-mode
>   :defer t
>   :custom
>   (rust-mode-treesitter-derive (and (fboundp 'treesit-available-p)
>                                     (treesit-available-p)))
>   (rust-ts-flymake-command '("cargo" "clippy")))
>
> ```
>
> May be this information help.

This gets rid of the initial errors from rust-ts-flymake, which may be
spurrious.  I'm not sure.  Maybe this should be the default for
rust-ts-flymake-command?  Either way, I think a patch like what I've
written is necessary to solve this general problem.

[0001-Delete-overlays-from-backends-that-no-longer-exist.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.