bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#50975: 28.0.60; mh-utils-tests fail with native compilation


From: Eli Zaretskii
Subject: bug#50975: 28.0.60; mh-utils-tests fail with native compilation
Date: Tue, 05 Oct 2021 15:31:13 +0300

> Cc: 50975@debbugs.gnu.org
> Date: Tue, 05 Oct 2021 07:54:41 +0000
> From:  Andrea Corallo via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Stephen Gildea <stepheng+emacs@gildea.com> writes:
> 
> > Thank you, Andrea, for the native-trampolines patch to mh-utils-tests.el.
> > In this patch, the test explicitly compiles trampolines before redefining
> > two functions that are defined in C.
> >
> > Is it necessary to provide trampolines at all for these short-lived test
> > functions?  The following works for me:
> >
> >     (mapc (lambda (x) (add-to-list 'native-comp-never-optimize-functions x))
> >           '(call-process file-directory-p))
> 
> Yes disabling the trampoline generation is another option.

We should document these caveats and the solutions for them in the ERT
manual.

> > Before redefining the functions, the test could create a dynamic local
> > binding for native-comp-never-optimize-functions and add to it as above.
> >
> > If that is a reasonable approach, can we go further?  Can the
> > native-compile code detect that this is a test and automatically
> > suppress trying to compile a trampoline, without the test having
> > to be aware of native-compile?
> 
> I don't think so.  The Emacs implementation has the right to use
> `call-process' to function and in general I think we really want to test
> the full implementation including trampolines as much as possible in all
> running tests we can.

I agree.  I don't think native-compilation should second-guess what
the programmer wants to do, because it's quite possible that some test
will want not to have a trampoline, for valid reasons.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]