GNU bug report logs - #25987
25.2; support gcc fixit notes

Previous Next

Full log

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

From: Andrea Corallo <akrl <at> sdf.org>
To: David Malcolm <dmalcolm <at> redhat.com>
Cc: 25987 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#25987: 25.2; support gcc fixit notes
Date: Thu, 15 Oct 2020 07:47:44 +0000

David Malcolm <dmalcolm <at> redhat.com> writes:

[...]

>> 
>> 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?

Yes, INSIDE_EMACS is not an option if we want to have GCC to depose
special files, would work if is just a matter of changing format but I
don't think this is the case (more on this below).

> 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).

Here come the trouble.  Ideally would be great to just emit to stderr
and integrate with compilation-mode.  My understanding is that this
would just not work for parallel builds as the output on stderr can be
intermixed, so the idea to dump to a special file.

I think (may be wrong) that this guided patching (but also the
navigation through the hierarchical hints that your static analyzer
produces) should be all handled by an ipotethical dedicated gcc-mode
that consume these json files.  I toyed already with this approach for
the static analyzer hints here [1].

You are correct suggesting that the connection from the stderr output in
compilation-mode may not be trivial but assuming this is a requirement
we have quite some info in the diagnostic message to search for the
corresponding diagnostic in the json.

"bar.c:350:3: error: invalid conversion to type 'foo_t'"

Maybe we could even add a diagnostic ID to make the connection simpler?

Or the other option is that we make it working saftely only for non
parallel builds just using stderr, but I don't think this is very future
proof, especially given you are constantly adding cool new features to
GCC we could make use of :)

  Andrea

[1] <https://gitlab.com/koral/gcc-analyzer-mode/-/blob/master/gcc-analyzer-mode.el>

Previous Next

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