From: Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: David Malcolm <dmalcolm@redhat.com>
Cc: 25987@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
Subject: bug#25987: 25.2; support gcc fixit notes
Date: Thu, 15 Oct 2020 07:47:44 +0000 [thread overview]
Message-ID: <xjf4kmwnd5r.fsf@sdf.org> (raw)
In-Reply-To: <b48450189c9f42b4f2ed602ce3dabc19f0405b57.camel@redhat.com> (David Malcolm's message of "Wed, 14 Oct 2020 18:43:33 -0400")
David Malcolm <dmalcolm@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>
next prev parent reply other threads:[~2020-10-15 7:47 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-05 21:47 bug#25987: 25.2; support gcc fixit notes Tom Tromey
2017-03-06 18:35 ` Eli Zaretskii
2017-03-07 13:54 ` Tom Tromey
2017-03-07 15:55 ` Eli Zaretskii
2017-03-08 18:34 ` Tom Tromey
2017-03-08 19:22 ` Eli Zaretskii
2017-03-09 4:20 ` Richard Stallman
2017-03-09 15:36 ` Eli Zaretskii
2017-03-08 18:44 ` Tom Tromey
2017-03-08 19:28 ` Eli Zaretskii
2017-03-09 16:37 ` Dmitry Gutov
2017-03-09 16:56 ` Eli Zaretskii
2017-03-09 17:37 ` Dmitry Gutov
2017-03-09 18:32 ` Eli Zaretskii
2017-03-09 21:26 ` Dmitry Gutov
2017-08-06 3:34 ` Tom Tromey
2017-03-09 16:18 ` Dmitry Gutov
2017-03-09 16:53 ` Eli Zaretskii
2017-03-09 17:49 ` Dmitry Gutov
2017-03-09 18:35 ` Eli Zaretskii
2017-08-06 3:31 ` Tom Tromey
2018-03-16 16:48 ` David Malcolm
2018-03-16 20:19 ` Eli Zaretskii
2020-10-06 18:17 ` David Malcolm
2020-10-06 18:37 ` Eli Zaretskii
2020-10-12 22:27 ` David Malcolm
2020-10-13 7:34 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-10-13 14:37 ` Eli Zaretskii
2020-10-14 22:43 ` David Malcolm
2020-10-15 7:47 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2021-01-14 21:37 ` David Malcolm
2020-10-15 13:53 ` Eli Zaretskii
2020-10-15 14:23 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-10-15 14:29 ` Eli Zaretskii
2020-10-15 14:44 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-10-20 14:52 ` David Malcolm
2020-10-20 15:54 ` Eli Zaretskii
2020-11-11 19:36 ` David Malcolm
2020-11-12 13:54 ` Eli Zaretskii
2020-11-13 16:47 ` David Malcolm
2020-11-14 14:21 ` Eli Zaretskii
2020-11-14 19:46 ` David Malcolm
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xjf4kmwnd5r.fsf@sdf.org \
--to=bug-gnu-emacs@gnu.org \
--cc=25987@debbugs.gnu.org \
--cc=akrl@sdf.org \
--cc=dmalcolm@redhat.com \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).