bug#58429: 29.0.50; inhibit-automatic-native-compilation does not work as expected.

[Andrea Corallo <akrl@sdf.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>, larsi@gnus.org, 58429@debbugs.gnu.org
>> Date: Thu, 13 Oct 2022 14:10:52 +0000
>> 
>> As Eli mentioned unfortunately we cannot disable trampolines.
>
> Btw, Andrea, can you help me understand better what does
> comp-enable-subr-trampolines do, when set to nil?  The doc string says
>
>   If non-nil enable primitive trampoline synthesis.
>   This makes primitive functions redefinable or advisable effectively.
>
> which seems to hint that when this is nil, primitives cannot be
> advised or redefined?

They can, but they will not take effect on Lisp code that is native
compiled (at speed 2), similarly to when they are called from C code.

> We set this variable to nil in startup.el if
> native-comp-available-p returns nil (which currently can only happen
> on MS-Windows), AFAIU with the intent to prevent Emacs from even
> trying to natively-compile anything, including trampolines.  But if
> Emacs cannot produce a trampoline, it means that primitives cannot be
> redefined, and we silently fail that?  Because (again, AFAIU)
> native-comp-available-p being nil does not prevent Emacs from loading
> *.eln files that are already compiled (because just loading them
> doesn't need libgccjit), is that right?

Correct, as you said Emacs will work, only we can't guarantee that
primitive redefinition will take the effect expected by the user (unless
of course trampolines were precompiled, in that case it's all good).

Bests

  Andrea