bug#34418: 27.0.50; Flymake adds markup to buffers not specified in `flymake-make-diagnostic'

[João Távora]

Philipp <p.stephani2@gmail.com> writes:

> 1. Create two scratch buffers *a* and *b* (e.g. C-x b *a* RET).
>
> 2. Insert some text into the buffers (e.g. "text a" and "text b",
>    respectively)
>
> 3. Add a trivial Flymake backend to buffer *b*.  E.g., select *b* and
>    run M-: with the following code:
>    
>    (add-hook 'flymake-diagnostic-functions
>              (lambda (report-fn &rest _args)
>                     (funcall report-fn (list (with-current-buffer "*a*"
>                     (flymake-make-diagnostic (current-buffer)
>                                              (point-min) (point-max)
>                      :error "message"))))))
>                      
>    Note that this backend adds a diagnostic for buffer *a*, not *b*.
>    
> 4. Enable Flymake mode in buffer *b*.
>
> Buffer *b* will now show a diagnostic, even though it was reported for
> buffer *a*.  This should either add a diagnostic for buffer *a* or
> signal an error.

Hi Phillip,

Sorry for the very slow turnaround.

The behaviour for handling the mismatch between the (1) the buffer
passed to flymake-make-diagnostic (2) the buffer where the report
function executes is unspecified and it is so by design.

I've yet to come to a good conclusion on what that behaviour should be,
and maybe you can help me.  Let's see some plausible real-world scenarios.

1. Some uses of Flymake, notably Eglot's via LSP (Language Server
   Protocol) can possibly take advantage of a good definition of this
   behaviour, for aggregating the errors reports across a project for
   example.  So `flymake-make-diagnostic` could be specified to take a
   BUFFER-OR-FILE, and we could heuristically decide to add the
   diagnostic to, say, a per-project database.

2. In another simpler scenario, checking .c file might issue errors for
   included .h files, and if that file is open in a buffer, we could go
   there and highlight the error.  Could we really?  Maybe not, because
   the error was probably generated for the on-disk copy of the .h file,
   whose contents might differ wildly from the buffer's.  Then again, a
   smart backend could consider that.

So maybe your "error" proposal makes sense, maybe it doesn't.  I'd
rather not commit to an API right now that could block evolution.

For now I've added a note to the manual's description of
flymake-make-diagnostic and a protection to flymake--handle-report that
will ignore such diagnostics.  What do you think?

João