GNU bug report logs - #78459
flymake related locations (ancillary diagnostics)

Previous Next

To reply to this bug, email your comments to 78459 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Emacs Bug Report <bug-gnu-emacs <at> gnu.org>
Cc: Spencer Baugh <sbaugh <at> janestreet.com>
Subject: flymake related locations (ancillary diagnostics)
Date: Fri, 16 May 2025 17:42:01 +0200

Flymake does not seem to have a way to attach related locations to a diagnostic. These are 'info' or 'note'-level messages that follow an error or warning and point out locations of interest, such as definitions or conflicting code. Current, they become independent diagnostics with no connection to the main message.

This is unfortunate, because:

* As interfaces typically sort diagnostics by location, these messages often become detached from their context. The text is usually not meant to be read in isolation, only as part of a single warning or error. Example:

myprog.q:98: error: variable 'zurk' is assigned an integer here
myprog.q:12: note: declared with type string here

When messages are sorted these come in the wrong order, possibly separated with several unrelated messages in-between.

* Since these info-messages make little sense on their own, it might be useful to hide them (from the table of diagnostics and in-code annotations) until the user selects their parent warning or error. That also cuts down on colliding squiggly underlines or whatever is used to mark locations in the code buffer.

* The LSP protocol has explicit provisions for ancillary messages ('relatedInformation') but Flymake cannot make use of it without some additional hacks.

There are various ways to fix this. For example:

A. Keep a list of auxiliary diagnostics in the diagnostic object. This seems easiest to work with and what I would suggest. It also corresponds directly to LSP, if I understand it right.

B. Tag all diagnostics that belong together in a group. This is what Flycheck does and would make interoperability easier, but doesn't say which diagnostic is the main one and in what order the auxiliary diagnostics should come.

What do you think?

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

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 78459 <at> debbugs.gnu.org,
 João Távora <joaotavora <at> gmail.com>
Subject: Re: bug#78459: flymake related locations (ancillary diagnostics)
Date: Tue, 20 May 2025 14:56:14 -0400

Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:
> Flymake does not seem to have a way to attach related locations to a
> diagnostic. These are 'info' or 'note'-level messages that follow an
> error or warning and point out locations of interest, such as
> definitions or conflicting code. Current, they become independent
> diagnostics with no connection to the main message.
>
> This is unfortunate, because:
>
> * As interfaces typically sort diagnostics by location, these messages often become detached from their context. The text is usually not meant to be read in isolation, only as part of a single warning or error. Example:
>
> myprog.q:98: error: variable 'zurk' is assigned an integer here
> myprog.q:12: note: declared with type string here
>
> When messages are sorted these come in the wrong order, possibly separated with several unrelated messages in-between.
>
> * Since these info-messages make little sense on their own, it might
> be useful to hide them (from the table of diagnostics and in-code
> annotations) until the user selects their parent warning or
> error. That also cuts down on colliding squiggly underlines or
> whatever is used to mark locations in the code buffer.

Yes, I agree that this is an important issue and that this should be
fixed.

> * The LSP protocol has explicit provisions for ancillary messages ('relatedInformation') but Flymake cannot make use of it without some additional hacks.

As do many other flymake backends.  I believe gcc for example can
generate errors which indicate multiple locations, e.g. when there's a
mismatch in type between two declaration sites.  (And, of relevance to
my site, the Dune build system has support for emitting "additional
error locations" associated with a diagnostic, but currently flymake
cannot use this.)

BTW, another feature this would enable is cycling between the locations
associated with a given error.  When an error is due to a mismatch
between two declarations, e.g., an auxiliary location might be in
another file and it might be useful to be able to jump to that location
and jump back.

> There are various ways to fix this. For example:
>
> A. Keep a list of auxiliary diagnostics in the diagnostic object. This seems easiest to work with and what I would suggest. It also corresponds directly to LSP, if I understand it right.
>
> B. Tag all diagnostics that belong together in a group. This is what Flycheck does and would make interoperability easier, but doesn't say which diagnostic is the main one and in what order the auxiliary diagnostics should come.

I also much prefer A.

Maybe the easiest thing to do would be to create individual diagnostic
objects for each auxiliary diagnostic, and have a backend report all of
them as individual diagnostics just as it would today - but to
additionally have a list in the "primary" diagnostic which has a
reference to each "auxiliary" diagnostic.  Then the flymake UI could
decide how to render these.  That's just my initial thought though.

Adding Joao to Cc, since he may have comments about how Eglot could make
use of this, and if there's any issues we're overlooking.

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

From: João Távora <joaotavora <at> gmail.com>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: Mattias Engdegård <mattias.engdegard <at> gmail.com>,
 78459 <at> debbugs.gnu.org
Subject: Re: bug#78459: flymake related locations (ancillary diagnostics)
Date: Tue, 20 May 2025 20:24:10 +0100

On Tue, May 20, 2025 at 7:56 PM Spencer Baugh <sbaugh <at> janestreet.com> wrote:

Hi Spencer, thanks for adding me. 

> > * As interfaces typically sort diagnostics by location, these
> > messages often become detached from their context. The text is
> > usually not meant to be read in isolation, only as part of a single
> > warning or error.  * Since these info-messages make little sense on
> > their own, it might be useful to hide them

I more or less sympathize with this change request, as I use a lot of
C/C++ and there are these types of diagnostics.  There's a specific case
where they bother me and it wasn't listed here.

It's when multiple errors hark back to the same misnamed variable/symbol
and there is an immense repetition of the green "note:" diagnostics such
as here:

int fo{};
    ├──────────────────────── 'fo' declared here
    ├────────────────────── 'fo' declared here
    └──────────────────── 'fo' declared here
void f1() { foo = 42; }
            └──────────────── Use of undeclared identifier 'foo'; did you mean 'fo'? 
void f2() { foo = 43; }
            └──────────────── Use of undeclared identifier 'foo'; did you mean 'fo'?
void f3() { foo = 44; }
            └──────────────── Use of undeclared identifier 'foo'; did you mean 'fo'?


However, not only doesn't this bother me that much, but it's really not
clear to me what could be done with this ancillary information.

Similarly, you succinctly describe two cases, but what does "selecting a
diagnostic" even mean?  I don't understand.

Let's forget the implementation for a while and think exactly what one
would want to the UI of:

1) the Flymake diagnostics buffer 
2) the in-code annotations (including the overlays created when flymake-show-diagnostics-at-end-of-line is non-nil).
3) the counters in the mode-line
4) the ElDoc outlet

...that could somehow take into account these groups or relations
between diagnostics.

Currently, except in rare cases, diagnostics are not interactive (in
those cases the UI is given by an external library, such as Eglot).
There is also no way to "filter" them unless a special UI outside of
Flymake is used.

Only after cleanly describing this UI should we worry about other
stuff. And yes, there is a plenty to worry about, such as what to do if
a backend tells Flymake to replace diagnostics in a region that link to
or are linked by a diagnostic outside that region.  And what to do if
linked diagnostics are in different loci (a locus may not be a buffer).

João

Previous Next

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