From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#25987: 25.2; support gcc fixit notes Date: Thu, 15 Oct 2020 07:47:44 +0000 Message-ID: References: <87lgsj1jle.fsf@tromey.com> <1521218887.2913.237.camel@redhat.com> <83muz7pyde.fsf@gnu.org> <83o8lf9p68.fsf@gnu.org> <26f277bb345f10efe6340ac4074960905064fc97.camel@redhat.com> <83362i2nul.fsf@gnu.org> Reply-To: Andrea Corallo Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4139"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 25987@debbugs.gnu.org, Eli Zaretskii To: David Malcolm Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 15 09:48:15 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kSxzj-0000yt-9q for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 15 Oct 2020 09:48:15 +0200 Original-Received: from localhost ([::1]:34098 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kSxzi-0004O4-7Z for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 15 Oct 2020 03:48:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41080) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kSxzW-0004Lv-Km for bug-gnu-emacs@gnu.org; Thu, 15 Oct 2020 03:48:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42527) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kSxzW-0006wI-BA for bug-gnu-emacs@gnu.org; Thu, 15 Oct 2020 03:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kSxzW-0007Yn-5V for bug-gnu-emacs@gnu.org; Thu, 15 Oct 2020 03:48:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Oct 2020 07:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs Original-Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.160274807329046 (code B ref 25987); Thu, 15 Oct 2020 07:48:02 +0000 Original-Received: (at 25987) by debbugs.gnu.org; 15 Oct 2020 07:47:53 +0000 Original-Received: from localhost ([127.0.0.1]:54073 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kSxzN-0007YP-DT for submit@debbugs.gnu.org; Thu, 15 Oct 2020 03:47:53 -0400 Original-Received: from mab.sdf.org ([205.166.94.33]:49892 helo=ma.sdf.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kSxzL-0007YH-6v for 25987@debbugs.gnu.org; Thu, 15 Oct 2020 03:47:51 -0400 Original-Received: from akrl by ma.sdf.org with local (Exim 4.92) (envelope-from ) id 1kSxzE-0005TA-UR; Thu, 15 Oct 2020 07:47:44 +0000 In-Reply-To: (David Malcolm's message of "Wed, 14 Oct 2020 18:43:33 -0400") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:190550 Archived-At: David Malcolm 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]