Package: emacs;
Reported by: Tom Tromey <tom <at> tromey.com>
Date: Sun, 5 Mar 2017 21:49:01 UTC
Severity: wishlist
Merged with 29004
Found in versions 25.2, 27.0.50
Message #85 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: Tue, 13 Oct 2020 07:34:02 +0000
David Malcolm <dmalcolm <at> redhat.com> writes: > On Tue, 2020-10-06 at 21:37 +0300, Eli Zaretskii wrote: >> > From: David Malcolm <dmalcolm <at> redhat.com> >> > Cc: 25987 <at> debbugs.gnu.org >> > Date: Tue, 06 Oct 2020 14:17:55 -0400 >> > >> > In GCC 11 we've revamped the column number handling in how we emit >> > diagnostics; see: >> > >> > https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555632.html >> > >> > GCC 11 diagnostics now (by default) should use actual column >> > numbers, >> > rather than byte counts. >> >> That's good news, thanks. >> >> > 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). >> >> So fixit hints will still count bytes? Or will GCC 11 emit such >> hints even without -fdiagnostics-parseable-fixits on the command >> line? >> >> > Note that characters != columns, or, at least, we have to be >> > careful >> > about what we mean. Consider the case of 🙂 aka SLIGHTLY SMILING >> > FACE >> > (U+1F642) which is a single unicode code point, but occupies two >> > columns, with its UTF-8 encoding requiring four bytes. >> > >> > 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? >> >> 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. >> >> > 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. >> >> Yes. >> >> > 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). >> >> 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. >> >> > 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?). >> >> 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. >> >> > Alternatively, we already have a JSON output option (-fdiagnostics- >> > format=json); perhaps something like that could be used? >> >> Emacs can parse JSON. What are the pros and cons of the JSON >> alternative wrt to the text alternative? > > The existing "-fdiagnostics-format=json" 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) >> >> 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 >= 11 or keep in the testsuite some pre cooked GCC output. Some tests should be easy to write. Andrea
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.