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: Tue, 13 Oct 2020 07:34:02 +0000 [thread overview]
Message-ID: <xjflfgao9zp.fsf@sdf.org> (raw)
In-Reply-To: <26f277bb345f10efe6340ac4074960905064fc97.camel@redhat.com> (David Malcolm's message of "Mon, 12 Oct 2020 18:27:29 -0400")
David Malcolm <dmalcolm@redhat.com> writes:
> On Tue, 2020-10-06 at 21:37 +0300, Eli Zaretskii wrote:
>> > From: David Malcolm <dmalcolm@redhat.com>
>> > Cc: 25987@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
next prev parent reply other threads:[~2020-10-13 7:34 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 [this message]
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
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=xjflfgao9zp.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).