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

[Andrea Corallo]

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 13:43:15 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> > 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?
>
> Yes.
>
>> If yes which one would you recommend we use?
>
> The latter, I think.
>
>> > Are we likely to write bytecode into this temporary file?
>> 
>> Yes definitely
>
> OK, then I think utf-8-emacs-unix it is.
>
>> >> 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).
>
> OK, thanks.

Right, I pushes the two commits to scratch/bug#48029 as I'll be soon
offline for the weekend.  Feel free to push them in the branch of
destination in case there's agreement on that, otherwise I'll take care
of it Monday.

Regards

  Andrea