bug#25987: 25.2; support gcc fixit notes

[David Malcolm <dmalcolm@redhat.com>]

On Tue, 2020-10-13 at 17:37 +0300, Eli Zaretskii wrote:
> > From: David Malcolm <dmalcolm@redhat.com>
> > Cc: 25987@debbugs.gnu.org
> > Date: Mon, 12 Oct 2020 18:27:29 -0400
> > 
> > I like how -fdiagnostics-parseable-fixits adds extra lines of
> > output,
> > with a prefix that's ought to be easy to detect.
> 
> Yes, I think that's preferable, indeed.

(nods)

> > BTW, does Emacs set anything in the environment that GCC could
> > detect?
> 
> Yes, Emacs sets INSIDE_EMACS when it runs a sub-process.

I'm increasingly warming to the idea of having it be enabled by an
environment variable, rather than a command-line option.

My thinking is that it's a pain to have to set up the build system to
inject a particular command-line option that's intended purely for
consumption by an IDE.  As an environment variable, the IDE can inject
it into the environment, regardless of whatever build system is in use,
and then consume the extra output.

(For reference GCC's existing environment variables are listed here:
https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html )

Something like GCC_EXTRA_DIAGNOSTIC_SOMETHING=foo, for some SOMETHING
and some foo?

I thought about maybe emitting JSON, which would be extendable.  But it
would have to be all on one line, which is less optimal, and would be
much more verbose than the existing format.

So maybe just use the existing format, but fixing it so that columns
are columns, as discussed.

So perhaps a fix-it aware Emacs mode could set this when compiling:

  GCC_EXTRA_DIAGNOSTIC_OUTPUT=fixits-v2

(v2 since v1 is the existing format from the cmdline option)

In his email, Andrea suggests outputting to a file.  How would 
that work?  It strikes me as making it difficult to associate the
output from stderr with that to the file, or would the output to the
file need to replace that from stderr (in which case what about lines
of output from "make"? or other build system messages, etc).

Arguably these various approaches are a poor-man's version of a
language server (I tried implementing that for GCC a few years ago, but
my proof of concept was not successful:
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01448.html )

> > Does Emacs have an automated test suite that could test this
> > feature?
> 
> Yes, see the tests in the test/ subdirectory of the Emacs tree.

(nods)

> > Another complication to consider: the locations in a fix-it hint
> > refer
> > to the original source file, before any changes are made.  If the
> > user
> > interface supports the user e.g. clicking on fix-it hints and
> > selectively apply them one by one, then after each fix-it hint is
> > applied, all locations after that point potentially need to be
> > "fixed
> > up" somehow, to reflect the changes to the buffer.
> 
> That could be handled automatically by defining a marker at each
> hint's location, then they will move as text is edited.

With the caveat that I'm a mere user of Emacs, that sounds reasonable.
(I mentioned it more as a complication I thought of that whoever
implements this on the Emacs side needs to be aware of).


Thoughts?

Dave