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: Tue, 13 Oct 2020 07:34:02 +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> Reply-To: Andrea Corallo Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9092"; 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 Tue Oct 13 09:35:11 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 1kSEpz-0002F5-3c for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 13 Oct 2020 09:35:11 +0200 Original-Received: from localhost ([::1]:59688 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kSEpy-0006ny-5E for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 13 Oct 2020 03:35:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41138) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kSEpp-0006nC-W7 for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2020 03:35:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33495) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kSEpp-0005Du-M3 for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2020 03:35:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kSEpp-00015u-Jh for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2020 03:35:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Oct 2020 07:35:01 +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.16025744574142 (code B ref 25987); Tue, 13 Oct 2020 07:35:01 +0000 Original-Received: (at 25987) by debbugs.gnu.org; 13 Oct 2020 07:34:17 +0000 Original-Received: from localhost ([127.0.0.1]:45041 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kSEp7-00014k-2Z for submit@debbugs.gnu.org; Tue, 13 Oct 2020 03:34:17 -0400 Original-Received: from mab.sdf.org ([205.166.94.33]:44112 helo=ma.sdf.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kSEp5-00014b-8P for 25987@debbugs.gnu.org; Tue, 13 Oct 2020 03:34:16 -0400 Original-Received: from akrl by ma.sdf.org with local (Exim 4.92) (envelope-from ) id 1kSEos-0000un-FT; Tue, 13 Oct 2020 07:34:02 +0000 In-Reply-To: <26f277bb345f10efe6340ac4074960905064fc97.camel@redhat.com> (David Malcolm's message of "Mon, 12 Oct 2020 18:27:29 -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:190401 Archived-At: David Malcolm writes: > On Tue, 2020-10-06 at 21:37 +0300, Eli Zaretskii wrote: >> > From: David Malcolm >> > Cc: 25987@debbugs.gnu.org >> > Date: Tue, 06 Oct 2020 14:17:55 -0400 >> >=20 >> > In GCC 11 we've revamped the column number handling in how we emit >> > diagnostics; see: >> >=20=20=20 >> > https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555632.html >> >=20 >> > GCC 11 diagnostics now (by default) should use actual column >> > numbers, >> > rather than byte counts. >>=20 >> That's good news, thanks. >>=20 >> > We haven't changed -fdiagnostics-parseable-fixits; it still emits >> > its >> > range information in terms of byte offsets (and e.g. Eclipse >> > already >> > consumes that option); this is bug-for-bug compatible with clang, I >> > believe (which had that option first). >>=20 >> So fixit hints will still count bytes? Or will GCC 11 emit such >> hints even without -fdiagnostics-parseable-fixits on the command >> line? >>=20 >> > Note that characters !=3D columns, or, at least, we have to be >> > careful >> > about what we mean. Consider the case of =F0=9F=99=82 aka SLIGHTLY SM= ILING >> > FACE >> > (U+1F642) which is a single unicode code point, but occupies two >> > columns, with its UTF-8 encoding requiring four bytes. >> >=20 >> > When I type it into an Emacs buffer, and look at the column number >> > I >> > see that Emacs appears to treat the character as occupying two >> > columns. >> > Is that the kind of column numbering you would want for machine- >> > readable fix-it hints? >>=20 >> Yes. Emacs computes the width of each character by using UCD, the >> Unicode Character Database (specifically, the EastAsianWidth.txt file >> that is part of the UCD). If GCC gets its column counts from a >> similar DB, then it will match what Emacs does. >>=20 >> > Similarly, the column numbering emitted by GCC 11 diagnostics is >> > affected by tab characters as tab stops, which seems to reflect >> > Emacs >> > behavior as well. >>=20 >> Yes. >>=20 >> > I can add an additional option for fix-it hints that's similar to >> > -fdiagnostics-parseable-fixits, but with a different output format >> > (or >> > to add an argument to that option, perhaps). >>=20 >> If an option is needed for getting the hints, then a special option >> which reports columns in hints will be appreciated, as it will make >> the Emacs support for processing those hints 100% accurate and devoid >> of encoding guesswork. >>=20 >> > Before I do that, I wanted to check that it would be consumable by >> > Emacs. What works for you? Would it help to send the proposed GCC >> > patch to this bug address (or to the emacs-devel list?). >>=20 >> I don't know how many people here build their own GCC, and thus could >> try the patch, but if sending the patch is not too much trouble, >> perhaps posting it on emacs-devel would be a good idea. If you do >> that, please cite this bug report, so that people who try that could >> respond here with their experience. >>=20 >> > Alternatively, we already have a JSON output option (-fdiagnostics- >> > format=3Djson); perhaps something like that could be used? >>=20 >> Emacs can parse JSON. What are the pros and cons of the JSON >> alternative wrt to the text alternative? > > The existing "-fdiagnostics-format=3Djson" GCC option replaces the > existing diagnostic output with a big blob of JSON to stderr, all on > one line. Although I implemented it, I now feel it to be rather half- > baked. > > I like how -fdiagnostics-parseable-fixits adds extra lines of output, > with a prefix that's ought to be easy to detect. > > BTW, does Emacs set anything in the environment that GCC could detect? Hi Dave, If we are searching for a way to ask GCC to dump a file instead of logging to sterr I think Emacs could easily set the env variable before invoking the compilation. Which one I think is to be agreed as would be probably used by a flymake back-end or same other special case as the one discussed. >> > Feature freeze for GCC 11 is about a month away; I'd love for Emacs >> > to >> > be able to consume GCC fix-it hints (and have GCC and Emacs fix my >> > typos for me) >>=20 >> Agreed; let's try to make that happen. > > I put together a test file showing various features to try to ensure > that GCC and Emacs interoperate on this. I'm attaching it. > > This can also be seen on Compiler Explorer at: > https://godbolt.org/z/zazejq > which adds the existing > -fdiagnostics-parseable-fixits -fdiagnostics-generate-patch > options. > > Ideas for other test cases are most welcome. > > Does Emacs have an automated test suite that could test this feature? > A long-postponed goal for me for GCC's testsuite is to ensure that fix- > it hints apply and actually fix the problem (clang's testsuite has > tests that verify this for clang's fix-it hints). Yes we have a testsuite, we could have a test that runs only with like GCC versions >=3D 11 or keep in the testsuite some pre cooked GCC output. Some tests should be easy to write. Andrea