bug#25987: 25.2; support gcc fixit notes

[David Malcolm <dmalcolm@redhat.com>]

On Tue, 2020-10-20 at 18:54 +0300, Eli Zaretskii wrote:
> > From: David Malcolm <dmalcolm@redhat.com>
> > Cc: 25987@debbugs.gnu.org
> > Date: Tue, 20 Oct 2020 10:52:05 -0400
> > 
> > One possible issue: in the final diagnostic, there's a fix-it hint
> > with
> > non-ASCII replacement text, replacing "two_pi" with "two_π" (where
> > the
> > final char in the latter is GREEK SMALL LETTER PI, U+03C0)
> > 
> > This replacement currently expressed as encoded bytes i.e:
> > 
> > fix-it:"demo.c":{51:10-51:16}:"two_\317\200"
> > 
> > where \317\200 is the octal-escaped representation of the two bytes
> > of
> > the UTF-8 encoding of the character.
> > 
> > Is this going to work for Emacs?
> 
> You mean, GCC doesn't actually emit the UTF-8 encoding of π, it emits
> its ASCII-fied representation?  We'd need to decode that, but is that
> really justified?  Why not emit UTF-8?

I have an implementation that simply emits UTF-8 in quotes, escaping
backslash, tab, newline, and doublequotes as before.  (we have to
escape at least newline, given that fix-it hint replacement text can
contain them, and we're using newline to terminate the parseable hint).

However, the filename also needs to be escaped.  Currently I'm applying
the same escaping rules to both filename and replacement text.
What is the encoding of the filename?  What if the bytes in a filename
aren't UTF-8 encoded?  How does emacs handle this case?  I tried
creating file with the name "byte 0xff" .txt, and with valid UTF-8 non-
ascii names and emacs reported them as \377.txt and with the UTF-8
names respectively, so perhaps I should simply emit the bytes and
pretend they are UTF-8?

Dave

[1] https://dwheeler.com/essays/fixing-unix-linux-filenames.html