bug#48029: 28.1; [native-comp] Function names with non-ascii characters

[Andrea Corallo <akrl@sdf.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: larsi@gnus.org, 48029@debbugs.gnu.org, jakanakaevangeli@chiru.no
>> Date: Fri, 08 Jul 2022 08:49:42 +0000
>> 
>> > Why do we have ";; -*-coding: nil; -*- "?  I think that's the problem:
>> > it should be ";; -*-coding: utf-8; -*- " instead.  Where does the nil
>> > come from?
>> 
>> AFAIR at the time we encountered a situation when one of these files was
>> read back with some other encoding (I guess it's heuristic?) so fixing
>> the encoding to nil solved the issue.
>
> You mean, bug#45433?

Yes that's the one.

> If the problem is EOL conversion, using
> utf-8-unix instead of utf-8 should take care of that.  Or maybe even
> use utf-8-emacs-unix.

Will utf-8-unix or utf-8-emacs-unix work on every OS?  If yes which one
would you recommend we use?

> Are we likely to write bytecode into this temporary file?

Yes definitely

>> > Lisp sources are by default UTF-8 encoded, so that should be the
>> > default for the temp file we write.  Bonus points for using the actual
>> > encoding of the Lisp source file there (which in very rare cases can
>> > be something other than UTF-8).
>> 
>> Ok attached the patch that sets it to utf-8, seems to work for me.
>> 
>> I'll have a look on how to spill the original coding system and get the
>> bonus points hopefully next week.
>
> Thanks.
>
>> Should this patch go in master or into the release branch?
>
> To the release branch, if Lars agrees.  But let's first try to see if
> bug#45433 is not back after the above change.

I can't see the test failing even removing the original fix so probably
some of the code in Emacs that is leveraged changed. This also suggests
the test is not really useful anymore (I'll double check and remove it).

  Andrea