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

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: max.brieiev@gmail.com, larsi@gnus.org, 58429@debbugs.gnu.org
> Date: Fri, 14 Oct 2022 20:10:57 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >   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).

Thanks.  I therefore extended the doc string of this variable (on the
emacs-28 branch) to make this crystal clear.