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

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

[jakanakaevangeli]

nonascii.el, saved with encoding utf-8-unix:

    ;; -*- lexical-binding: t; -*-
    (defun nonascii-test-žžž (arg)
      (when arg t))

Visit it and M-x emacs-lisp-native-compile-and-load.
A function called "nonascii-test-žžž" will be defined.

Best regards.


In GNU Emacs 28.0.50 (build 6, x86_64-pc-linux-gnu, GTK+ Version 3.24.28, cairo version 1.17.4)
 of 2021-04-25 built on miha-pc
Repository revision: 83a915d3dfafd5f3d737afe1e13b75e4dd3aef96
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12010000
System Description: Arch Linux

Configured using:
 'configure --with-native-compilation --prefix=/usr'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XDBE XIM XPM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.utf8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: ELisp/l

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source eieio eieio-core eieio-loaddefs
password-cache json map mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils thingatpt help-fns radix-tree time-date
compile text-property-search comint ansi-color ring comp comp-cstr
warnings subr-x rx cl-seq cl-macs cl-extra help-mode seq byte-opt gv
cl-loaddefs cl-lib bytecomp byte-compile cconv iso-transl tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win
x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process nativecomp
emacs)

Memory information:
((conses 16 99729 11493)
 (symbols 48 8466 0)
 (strings 32 25222 2833)
 (string-bytes 1 834149)
 (vectors 16 23269)
 (vector-slots 8 992809 132999)
 (floats 8 29 63)
 (intervals 56 269 0)
 (buffers 992 15))

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

[Lars Ingebrigtsen]

jakanakaevangeli@chiru.no writes:

> nonascii.el, saved with encoding utf-8-unix:
>
>     ;; -*- lexical-binding: t; -*-
>     (defun nonascii-test-žžž (arg)
>       (when arg t))
>
> Visit it and M-x emacs-lisp-native-compile-and-load.
> A function called "nonascii-test-žžž" will be defined.

I can reproduce this problem here, too (under Debian/bullseye).  (And
this works fine when doing non-native compilation.)

I've added Andrea to the CCs.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> jakanakaevangeli@chiru.no writes:
>
>> nonascii.el, saved with encoding utf-8-unix:
>>
>>     ;; -*- lexical-binding: t; -*-
>>     (defun nonascii-test-žžž (arg)
>>       (when arg t))
>>
>> Visit it and M-x emacs-lisp-native-compile-and-load.
>> A function called "nonascii-test-žžž" will be defined.
>
> I can reproduce this problem here, too (under Debian/bullseye).  (And
> this works fine when doing non-native compilation.)
>
> I've added Andrea to the CCs.

Thanks Lars,

it's in my todo, I'll try to have a look this coming week.

  Andrea

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

[Lars Ingebrigtsen]

Andrea Corallo <akrl@sdf.org> writes:

>>> nonascii.el, saved with encoding utf-8-unix:
>>>
>>>     ;; -*- lexical-binding: t; -*-
>>>     (defun nonascii-test-žžž (arg)
>>>       (when arg t))
>>>
>>> Visit it and M-x emacs-lisp-native-compile-and-load.
>>> A function called "nonascii-test-žžž" will be defined.
>>
>> I can reproduce this problem here, too (under Debian/bullseye).  (And
>> this works fine when doing non-native compilation.)
>>
>> I've added Andrea to the CCs.
>
> Thanks Lars,
>
> it's in my todo, I'll try to have a look this coming week.

This is still the case in Emacs 29 -- did you get any further with this?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Andrea Corallo]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>>>> nonascii.el, saved with encoding utf-8-unix:
>>>>
>>>>     ;; -*- lexical-binding: t; -*-
>>>>     (defun nonascii-test-žžž (arg)
>>>>       (when arg t))
>>>>
>>>> Visit it and M-x emacs-lisp-native-compile-and-load.
>>>> A function called "nonascii-test-žžž" will be defined.
>>>
>>> I can reproduce this problem here, too (under Debian/bullseye).  (And
>>> this works fine when doing non-native compilation.)
>>>
>>> I've added Andrea to the CCs.
>>
>> Thanks Lars,
>>
>> it's in my todo, I'll try to have a look this coming week.
>
> This is still the case in Emacs 29 -- did you get any further with this?

Hi Lars,

nope, had no time to progress with this.

  Andrea

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

[Eli Zaretskii]

> Cc: 48029@debbugs.gnu.org, jakanakaevangeli@chiru.no
> From: Andrea Corallo <akrl@sdf.org>
> Date: Mon, 04 Jul 2022 08:51:01 +0000
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > Andrea Corallo <akrl@sdf.org> writes:
> >
> >>>> nonascii.el, saved with encoding utf-8-unix:
> >>>>
> >>>>     ;; -*- lexical-binding: t; -*-
> >>>>     (defun nonascii-test-žžž (arg)
> >>>>       (when arg t))
> >>>>
> >>>> Visit it and M-x emacs-lisp-native-compile-and-load.
> >>>> A function called "nonascii-test-žžž" will be defined.
> >>>
> >>> I can reproduce this problem here, too (under Debian/bullseye).  (And
> >>> this works fine when doing non-native compilation.)
> >>>
> >>> I've added Andrea to the CCs.
> >>
> >> Thanks Lars,
> >>
> >> it's in my todo, I'll try to have a look this coming week.
> >
> > This is still the case in Emacs 29 -- did you get any further with this?
> 
> Hi Lars,
> 
> nope, had no time to progress with this.

Andrea, can you point to the place (or places) where the name of the
function is generated in this scenario?  Perhaps armed with that
knowledge, fixing the problem will not be too hard.

Thanks.

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

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: 48029@debbugs.gnu.org, jakanakaevangeli@chiru.no
>> From: Andrea Corallo <akrl@sdf.org>
>> Date: Mon, 04 Jul 2022 08:51:01 +0000
>> 
>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>> 
>> > Andrea Corallo <akrl@sdf.org> writes:
>> >
>> >>>> nonascii.el, saved with encoding utf-8-unix:
>> >>>>
>> >>>>     ;; -*- lexical-binding: t; -*-
>> >>>>     (defun nonascii-test-žžž (arg)
>> >>>>       (when arg t))
>> >>>>
>> >>>> Visit it and M-x emacs-lisp-native-compile-and-load.
>> >>>> A function called "nonascii-test-žžž" will be defined.
>> >>>
>> >>> I can reproduce this problem here, too (under Debian/bullseye).  (And
>> >>> this works fine when doing non-native compilation.)
>> >>>
>> >>> I've added Andrea to the CCs.
>> >>
>> >> Thanks Lars,
>> >>
>> >> it's in my todo, I'll try to have a look this coming week.
>> >
>> > This is still the case in Emacs 29 -- did you get any further with this?
>> 
>> Hi Lars,
>> 
>> nope, had no time to progress with this.
>
> Andrea, can you point to the place (or places) where the name of the
> function is generated in this scenario?  Perhaps armed with that
> knowledge, fixing the problem will not be too hard.
>
> Thanks.
>

Sure,

the place where the C function name is generated is `comp-c-func-name'
at comp.el:1175.

ATM I'm not 100% sure the fix limited to this tho.

BR

  Andrea

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

[Lars Ingebrigtsen]

Andrea Corallo <akrl@sdf.org> writes:

>>> >>>> Visit it and M-x emacs-lisp-native-compile-and-load.
>>> >>>> A function called "nonascii-test-žžž" will be defined.

[...]

> the place where the C function name is generated is `comp-c-func-name'
> at comp.el:1175.
>
> ATM I'm not 100% sure the fix limited to this tho.

This isn't about the C function name, though -- the problem is that the
Emacs function name is "nonascii-test-žžž" instead of
"nonascii-test-žžž".

Unless the C function name is then later translated back into a
doubly-encoded Lisp function name somehow.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Andrea Corallo]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>>>> >>>> Visit it and M-x emacs-lisp-native-compile-and-load.
>>>> >>>> A function called "nonascii-test-žžž" will be defined.
>
> [...]
>
>> the place where the C function name is generated is `comp-c-func-name'
>> at comp.el:1175.
>>
>> ATM I'm not 100% sure the fix limited to this tho.
>
> This isn't about the C function name, though -- the problem is that the
> Emacs function name is "nonascii-test-žžž" instead of
> "nonascii-test-žžž".

Ah that's a very good point!  Okay I had a look:

We have the symbol `nonascii-test-žžž' correct into our pipeline.

Then we prepare the file that will be executed by the subprocess that
will do the actual compilation, we do this in `comp-final'.

Here when we print `nonascii-test-žžž' using `prin1-to-string' this
becomes "nonascii-test-\x017e\x017e\x017e" (exploring it with the
debugger).

This is then stored in the temp file I mentioned, the file has on top
";; -*-coding: nil; -*- " and the symbol is shown as
"nonascii-test-\305\276\305\276\305\276" if I visit it on my emacs.

Now two options, either we are not printing it as we should or either
the reader doesn't know he has to handle these non ascii characters
while reading back.

I'm no expert in this area, I guess will be evident to experts what we
are not doing correctly here.

Thanks!

  Andrea

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

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, 48029@debbugs.gnu.org,
>         jakanakaevangeli@chiru.no
> Date: Thu, 07 Jul 2022 20:51:48 +0000
> 
> We have the symbol `nonascii-test-žžž' correct into our pipeline.
> 
> Then we prepare the file that will be executed by the subprocess that
> will do the actual compilation, we do this in `comp-final'.
> 
> Here when we print `nonascii-test-žžž' using `prin1-to-string' this
> becomes "nonascii-test-\x017e\x017e\x017e" (exploring it with the
> debugger).
> 
> This is then stored in the temp file I mentioned, the file has on top
> ";; -*-coding: nil; -*- " and the symbol is shown as
> "nonascii-test-\305\276\305\276\305\276" if I visit it on my emacs.
> 
> Now two options, either we are not printing it as we should or either
> the reader doesn't know he has to handle these non ascii characters
> while reading back.
> 
> I'm no expert in this area, I guess will be evident to experts what we
> are not doing correctly here.

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?

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).

Thanks.

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

[Andrea Corallo]

[-- Attachment #1: Type: text/plain, Size: 1973 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>, 48029@debbugs.gnu.org,
>>         jakanakaevangeli@chiru.no
>> Date: Thu, 07 Jul 2022 20:51:48 +0000
>> 
>> We have the symbol `nonascii-test-žžž' correct into our pipeline.
>> 
>> Then we prepare the file that will be executed by the subprocess that
>> will do the actual compilation, we do this in `comp-final'.
>> 
>> Here when we print `nonascii-test-žžž' using `prin1-to-string' this
>> becomes "nonascii-test-\x017e\x017e\x017e" (exploring it with the
>> debugger).
>> 
>> This is then stored in the temp file I mentioned, the file has on top
>> ";; -*-coding: nil; -*- " and the symbol is shown as
>> "nonascii-test-\305\276\305\276\305\276" if I visit it on my emacs.
>> 
>> Now two options, either we are not printing it as we should or either
>> the reader doesn't know he has to handle these non ascii characters
>> while reading back.
>> 
>> I'm no expert in this area, I guess will be evident to experts what we
>> are not doing correctly here.
>
> 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.

> 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.

Should this patch go in master or into the release branch?

Regards

  Andrea


[-- Attachment #2: 0001-Mark-async-worker-tmp-file-as-utf-8-bug-48029.patch --]
[-- Type: text/x-diff, Size: 2295 bytes --]

From 76f18b38989e13136c191d40ef5c497161947394 Mon Sep 17 00:00:00 2001
From: Andrea Corallo <akrl@sdf.org>
Date: Fri, 8 Jul 2022 10:27:45 +0200
Subject: [PATCH] Mark async worker tmp file as utf-8 (bug#48029)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lisp/emacs-lisp/comp.el (comp-final): Mark async worker tmp file
as utf-8.
* test/src/comp-tests.el (48029-1): New test.
* test/src/comp-resources/comp-test-funcs.el
(comp-test-48029-nonascii-žžž-f): New function.
---
 lisp/emacs-lisp/comp.el                    | 2 +-
 test/src/comp-resources/comp-test-funcs.el | 2 ++
 test/src/comp-tests.el                     | 5 +++++
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/lisp/emacs-lisp/comp.el b/lisp/emacs-lisp/comp.el
index 73285e0f24..9555bc8bd1 100644
--- a/lisp/emacs-lisp/comp.el
+++ b/lisp/emacs-lisp/comp.el
@@ -3693,7 +3693,7 @@ comp-final
 				 (file-name-base output) "-")
 			 nil ".el")))
 	(with-temp-file temp-file
-          (insert ";; -*-coding: nil; -*-\n")
+          (insert ";; -*-coding: utf-8; -*-\n")
           (mapc (lambda (e)
                   (insert (prin1-to-string e)))
                 expr))
diff --git a/test/src/comp-resources/comp-test-funcs.el b/test/src/comp-resources/comp-test-funcs.el
index 0a60f4d6cc..9092f040c8 100644
--- a/test/src/comp-resources/comp-test-funcs.el
+++ b/test/src/comp-resources/comp-test-funcs.el
@@ -515,6 +515,8 @@ comp-test-47868-3-f
 (defun comp-test-47868-4-f ()
   #(" " 0 1 (face font-lock-keyword-face)))
 
+(defun comp-test-48029-nonascii-žžž-f (arg)
+  (when arg t))
 
 \f
 ;;;;;;;;;;;;;;;;;;;;
diff --git a/test/src/comp-tests.el b/test/src/comp-tests.el
index e7b534d00e..c7e81298d2 100644
--- a/test/src/comp-tests.el
+++ b/test/src/comp-tests.el
@@ -532,6 +532,11 @@ comp-test-47868-1
   (should (eq (comp-test-47868-1-f) (comp-test-47868-3-f)))
   (should (eq (comp-test-47868-2-f) (comp-test-47868-4-f))))
 
+(comp-deftest 48029-1 ()
+  "<https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-07/msg00666.html>"
+  (should (subr-native-elisp-p
+           (symbol-function 'comp-test-48029-nonascii-žžž-f))))
+
 \f
 ;;;;;;;;;;;;;;;;;;;;;
 ;; Tromey's tests. ;;
-- 
2.25.1

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

[Eli Zaretskii]

> 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?  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.

Are we likely to write bytecode into this temporary file?

> > 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.

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 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

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

[Eli Zaretskii]

> 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.

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

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> To the release branch, if Lars agrees.  But let's first try to see if
> bug#45433 is not back after the above change.

If it doesn't regress bug#45433, then it's fine by me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Andrea Corallo <akrl@sdf.org>,  48029@debbugs.gnu.org,
>   jakanakaevangeli@chiru.no
> Date: Sun, 10 Jul 2022 14:56:40 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > To the release branch, if Lars agrees.  But let's first try to see if
> > bug#45433 is not back after the above change.
> 
> If it doesn't regress bug#45433, then it's fine by me.

Andrea says he cannot reproduce bug#45433 even if he removes the fix
entirely.  I guess some other change fixed it.

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

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Cc: Andrea Corallo <akrl@sdf.org>,  48029@debbugs.gnu.org,
>>   jakanakaevangeli@chiru.no
>> Date: Sun, 10 Jul 2022 14:56:40 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > To the release branch, if Lars agrees.  But let's first try to see if
>> > bug#45433 is not back after the above change.
>> 
>> If it doesn't regress bug#45433, then it's fine by me.
>
> Andrea says he cannot reproduce bug#45433 even if he removes the fix
> entirely.  I guess some other change fixed it.

Correct.  I think we should come to a conclusion on the branch to target
so we can push the fix we already have and maximize its verification.

BR

  Andrea

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

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 48029@debbugs.gnu.org,
>         jakanakaevangeli@chiru.no
> Date: Tue, 12 Jul 2022 14:24:36 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Lars Ingebrigtsen <larsi@gnus.org>
> >> Cc: Andrea Corallo <akrl@sdf.org>,  48029@debbugs.gnu.org,
> >>   jakanakaevangeli@chiru.no
> >> Date: Sun, 10 Jul 2022 14:56:40 +0200
> >> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> > To the release branch, if Lars agrees.  But let's first try to see if
> >> > bug#45433 is not back after the above change.
> >> 
> >> If it doesn't regress bug#45433, then it's fine by me.
> >
> > Andrea says he cannot reproduce bug#45433 even if he removes the fix
> > entirely.  I guess some other change fixed it.
> 
> Correct.  I think we should come to a conclusion on the branch to target
> so we can push the fix we already have and maximize its verification.

I think the conclusion is to put it on the release branch.  Lars?

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I think the conclusion is to put it on the release branch.  Lars?

Yup.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Andrea Corallo]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> I think the conclusion is to put it on the release branch.  Lars?
>
> Yup.

Done.

Thanks

  Andrea

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

[Andrea Corallo]

Andrea Corallo <akrl@sdf.org> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>> I think the conclusion is to put it on the release branch.  Lars?
>>
>> Yup.
>
> Done.
>
> Thanks
>
>   Andrea

Ok closing this as it was solved.

BR

  Andrea