bug#51308: 29.0.50; A number of tests fail with AOT

bug#51308: 29.0.50; A number of tests fail with AOT

[Lars Ingebrigtsen]

With

NATIVE_FULL_AOT=1 make -j16 bootstrap

a number of tests fail:

SUMMARY OF TEST RESULTS
-----------------------
Files examined: 375
Ran 5645 tests, 5513 results as expected, 8 unexpected, 124 skipped
5 files contained unexpected results:
  lisp/net/socks-tests.log
  lisp/loadhist-tests.log
  lisp/hi-lock-tests.log
  lisp/emacs-lisp/ert-tests.log
  lisp/calendar/todo-mode-tests.log

I have not tried to debug this further, but a cursory look at the
backtraces seems to suggest the failures might have something to do with
redefining functions -- but that's just a guess.


In GNU Emacs 29.0.50 (build 39, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.16.0)
 of 2021-10-20 built on elva
Repository revision: 62591c164cd6d0b0555e11b160ffa81bd3bb010f
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux bookworm/sid


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

bug#51308: 29.0.50; A number of tests fail with AOT

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 20 Oct 2021 20:20:44 +0200
> Cc: Andrea Corallo <akrl@sdf.org>
> 
> Files examined: 375
> Ran 5645 tests, 5513 results as expected, 8 unexpected, 124 skipped
> 5 files contained unexpected results:
>   lisp/net/socks-tests.log
>   lisp/loadhist-tests.log
>   lisp/hi-lock-tests.log
>   lisp/emacs-lisp/ert-tests.log
>   lisp/calendar/todo-mode-tests.log
> 
> I have not tried to debug this further, but a cursory look at the
> backtraces seems to suggest the failures might have something to do with
> redefining functions -- but that's just a guess.

Code that redefines functions which are in *.eln files should disable
native-compilation.

bug#51308: 29.0.50; A number of tests fail with AOT

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Code that redefines functions which are in *.eln files should disable
> native-compilation.

Isn't it possible to flet natively compiled functions?

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

bug#51308: 29.0.50; A number of tests fail with AOT

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> 5 files contained unexpected results:
>   lisp/net/socks-tests.log

This is now fixed.

>   lisp/loadhist-tests.log

This is a bug-ish.  If dired isn't natively-compiled:

(locate-file "dired" load-path (get-load-suffixes))
=> "/home/larsi/src/emacs/trunk/lisp/dired.elc"

But if it is, then we return the .el file instead:

(locate-file "dired" load-path (get-load-suffixes))
=> "/home/larsi/src/emacs/trunk/lisp/dired.el"

But load-history has:

 ("/home/larsi/src/emacs/emacs-28/lisp/dired.elc"

Which means that we can't find the .elc file by looking into
load-history based on locate-file.

Returning the .elc file would fix this, but I don't know what other
repercussions there might be.

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

bug#51308: bug#52138: 29.0.50; Some tests fail on emba when run with native compilation

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> This is a bug-ish.  If dired isn't natively-compiled:
>
> (locate-file "dired" load-path (get-load-suffixes))
> => "/home/larsi/src/emacs/trunk/lisp/dired.elc"
>
> But if it is, then we return the .el file instead:
>
> (locate-file "dired" load-path (get-load-suffixes))
> => "/home/larsi/src/emacs/trunk/lisp/dired.el"
>
> But load-history has:
>
>  ("/home/larsi/src/emacs/emacs-28/lisp/dired.elc"
>
> Which means that we can't find the .elc file by looking into
> load-history based on locate-file.
>
> Returning the .elc file would fix this, but I don't know what other
> repercussions there might be.

I've now done this change (which fixes this test failure), and I don't
see any other regressions, so I've pushed it to Emacs 29.

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

bug#51308: bug#52138: 29.0.50; Some tests fail on emba when run with native compilation

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sat, 12 Mar 2022 22:32:57 +0100
> Cc: 52138@debbugs.gnu.org, Andrea Corallo <akrl@sdf.org>
> 
> > Returning the .elc file would fix this, but I don't know what other
> > repercussions there might be.
> 
> I've now done this change (which fixes this test failure), and I don't
> see any other regressions, so I've pushed it to Emacs 29.

Did you check that loading a .elc file via load-library still triggers
async native-compilation when there's no .eln file or it is not
up-to-date with the .el file?  And what about loading a .el or .elc
file with an explicit extension -- that should NOT trigger
native-compilation even if there's no up-to-date .eln file.

bug#51308: bug#52138: 29.0.50; Some tests fail on emba when run with native compilation

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Did you check that loading a .elc file via load-library still triggers
> async native-compilation when there's no .eln file or it is not
> up-to-date with the .el file?

Yes, I didn't see any noticeable difference before or after the patch in
that regard.

> And what about loading a .el or .elc
> file with an explicit extension -- that should NOT trigger
> native-compilation even if there's no up-to-date .eln file.

Didn't try that.  Let's see...  if I do

(load "~/src/emacs/trunk/lisp/battery.el")

or

(load "~/src/emacs/trunk/lisp/battery.elc")

then no .eln compilation is started.

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

bug#52138: bug#51308: bug#52138: 29.0.50; Some tests fail on emba when run with native compilation

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 51308@debbugs.gnu.org,  52138@debbugs.gnu.org,  akrl@sdf.org
> Date: Sun, 13 Mar 2022 15:14:56 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > And what about loading a .el or .elc
> > file with an explicit extension -- that should NOT trigger
> > native-compilation even if there's no up-to-date .eln file.
> 
> Didn't try that.  Let's see...  if I do
> 
> (load "~/src/emacs/trunk/lisp/battery.el")
> 
> or
> 
> (load "~/src/emacs/trunk/lisp/battery.elc")
> 
> then no .eln compilation is started.

Great, that's the correct behavior.  Thanks.

bug#51308: 29.0.50; A number of tests fail with AOT

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Files examined: 375
> Ran 5645 tests, 5513 results as expected, 8 unexpected, 124 skipped
> 5 files contained unexpected results:
>   lisp/net/socks-tests.log
>   lisp/loadhist-tests.log
>   lisp/hi-lock-tests.log
>   lisp/emacs-lisp/ert-tests.log
>   lisp/calendar/todo-mode-tests.log

I've now fixed

>   lisp/hi-lock-tests.log
>   lisp/calendar/todo-mode-tests.log

which were about wrong number of parameters (which native-comp is more
strict about) when redefining functions.

>   lisp/emacs-lisp/ert-tests.log

is about

(backtrace-frame-fun (car (ert-test-failed-backtrace result)))
=> ert-fail

(car (ert-test-failed-backtrace result))
=> #s(backtrace-frame t ert-fail ("foo") nil ((debugger-may-continue . t) (inhibit-redisplay) (inhibit-debugger . t) (inhibit-changing-match-data)) nil nil)

while it's `signal' when ert isn't natively compiled.

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

bug#51308: bug#52138: 29.0.50; Some tests fail on emba when run with native compilation

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> while it's `signal' when ert isn't natively compiled.

I've now fixed this in the test, but it's not clear that that's the
correct thing to do here.  But at least this makes EMBA have one less
failure.

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