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

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

[Max Brieiev]

I have configured Emacs with --with-native-compilation (for the first
time) and it seemingly compiled fine.

However, libgccjit on my system seems to be broken (or something like
that). When Emacs starts I see lots of native compilation errors.

So I decided to (temporarily) disable this feature until I figure out
what is wrong with my system.

I start Emacs like this:

    $ EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION=t emacs

Now it starts without compilation errors. And it works just fine during
basic usage like sending this bug report.

However, when I invoke magit, I see this:

    Deleting /tmp/comp-lambda-RCGJQI.eln
    comp--native-compile: Native compiler error: (lambda (&rest arg1) (let ((f #'make-process)) (apply f arg1))), "Compiling /tmp/comp-lambda-RCGJQI.eln...
    x86_64-unknown-linux-gnu-gcc-10.3.0: fatal error: cannot execute ‘as’: execvp: No such file or directory
    compilation terminated.

which makes the package unusable.

Some other packages also produce similar errors, but others like Eglot
work just fine.

I am not sure that this is a valid bug report, because the manual says
that the compiler may still be invoked even if
inhibit-automatic-native-compilation is non-nil, though the result
shouldn't be written to disk. But if I understand the output in Message
buffer, it tries to write the file to disk?

Would it be hard to enhance this feature to completely disable native
compiler?

In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.30, cairo version 1.16.0)
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Guix System

Configured using:
 'configure
 CONFIG_SHELL=/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/bash
 SHELL=/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/bash
 --prefix=/gnu/store/jz3p1yvfm53j28dmyxpkjji1mimfi5lz-emacs-next-git.master
 --enable-fast-install --with-modules --with-cairo
 --with-native-compilation --disable-build-details'

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

Important settings:
  value of $EMACSLOADPATH: /home/max/.guix-profile/share/emacs/site-lisp:/gnu/store/jz3p1yvfm53j28dmyxpkjji1mimfi5lz-emacs-next-git.master/share/emacs/29.0.50/lisp
  value of $LANG: en_US.utf8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  shell-dirtrack-mode: t
  paredit-mode: t
  hl-line-mode: t
  global-corfu-mode: t
  corfu-mode: t
  marginalia-mode: t
  vertico-mode: t
  override-global-mode: t
  which-function-mode: t
  savehist-mode: t
  repeat-mode: t
  recentf-mode: t
  pixel-scroll-precision-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  context-menu-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/home/max/.emacs.d/elpa/transient-20220918.2101/transient hides /gnu/store/jz3p1yvfm53j28dmyxpkjji1mimfi5lz-emacs-next-git.master/share/emacs/29.0.50/lisp/transient

Features:
(shadow sort mail-extr emacsbug cl-print package-x js2-mode etags
fileloop generator js cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs dired-aux eglot array
filenotify jsonrpc ert ewoc xref flymake-proc flymake thingatpt compile
shell pcomplete comint ansi-osc server ansi-color magit-mode transient
comp comp-cstr warnings magit-git magit-base magit-section format-spec
crm dash compat-27 compat-26 rx add-log mule-util cursor-sensor vc-git
diff-mode vc vc-dispatcher project paredit-menu paredit hl-line message
yank-media puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg
rfc6068 epg-config mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader smtpmail sendmail rfc2047 rfc2045
ietf-drums gnus nnheader gnus-util time-date mail-utils range mm-util
mail-prsvr modus-operandi-theme modus-themes pcase files-x
consult-vertico consult compat-28 compat compat-macs bookmark
text-property-search corfu orderless cus-edit pp icons marginalia
vertico edmacro kmacro cl-extra use-package use-package-ensure
use-package-delight use-package-diminish use-package-bind-key bind-key
easy-mmode use-package-core which-func imenu edebug debug backtrace
find-func savehist repeat recentf tree-widget wid-edit pixel-scroll
cua-base cus-load guix-emacs corfu-autoloads eglot-autoloads
embark-consult-autoloads consult-autoloads embark-autoloads
geiser-guile-autoloads geiser-impl help-fns radix-tree help-mode
geiser-custom geiser-base ring geiser-autoloads js2-mode-autoloads
magit-autoloads git-commit-autoloads magit-section-autoloads
dash-autoloads marginalia-autoloads orderless-autoloads
paredit-menu-autoloads paredit-autoloads transient-autoloads
use-package-autoloads bind-key-autoloads vertico-autoloads
with-editor-autoloads info package browse-url url url-proxy url-privacy
url-expand url-methods url-history url-cookie generate-lisp-file
url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq
eieio eieio-core cl-macs password-cache json subr-x map byte-opt gv
bytecomp byte-compile cconv url-vars cl-loaddefs cl-lib rmc iso-transl
tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode 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 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 nadvice seq
simple cl-generic indonesian philippine 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 emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 444658 55840)
 (symbols 48 29470 55)
 (strings 32 89288 3681)
 (string-bytes 1 3667419)
 (vectors 16 50532)
 (vector-slots 8 818358 54689)
 (floats 8 373 261)
 (intervals 56 766 266)
 (buffers 1000 16))

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

[Lars Ingebrigtsen]

Max Brieiev <max.brieiev@gmail.com> writes:

> Now it starts without compilation errors. And it works just fine during
> basic usage like sending this bug report.
>
> However, when I invoke magit, I see this:
>
>     Deleting /tmp/comp-lambda-RCGJQI.eln
>     comp--native-compile: Native compiler error: (lambda (&rest arg1) (let ((f #'make-process)) (apply f arg1))), "Compiling /tmp/comp-lambda-RCGJQI.eln...
>     x86_64-unknown-linux-gnu-gcc-10.3.0: fatal error: cannot execute ‘as’: execvp: No such file or directory
>     compilation terminated.
>
> which makes the package unusable.

The setting affects whether your Emacs decides to native-compile during
normal operation.  But here it sounds like Magit is trying to use the
native-compiler anyway, and fails (since your libgccjit is broken).

I think this is just a reflection on the general broken-ness of your
system -- you can't expect packages like Magit to work under these
circumstances, so you should fix your system (or not use a nativecomp
Emacs if your system doesn't support it).

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

[Max Brieiev]

Then I think this bug report can be closed.

Out of curiosity, isn't native compilation something that should be
working out of the box, meaning that a package shouldn't be dealing with
it directly? Why would magit (and other packages) run native-compiler
explicitly?

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

[Andrea Corallo]

Max Brieiev <max.brieiev@gmail.com> writes:

> Then I think this bug report can be closed.
>
> Out of curiosity, isn't native compilation something that should be
> working out of the box, meaning that a package shouldn't be dealing with
> it directly? Why would magit (and other packages) run native-compiler
> explicitly?

Exactly.  I don't think magit is trying to invoke the native compiler
directly (I don't see any trace of that in magit's source code).  Also
other packages are reported to show the same issue (probably the one
with no .eln already available).

If this is the case is just `inhibit-automatic-native-compilation' not
doing what it promises (read being broken).

  Andrea

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

[Lars Ingebrigtsen]

Andrea Corallo <akrl@sdf.org> writes:

> Exactly.  I don't think magit is trying to invoke the native compiler
> directly (I don't see any trace of that in magit's source code).  Also
> other packages are reported to show the same issue (probably the one
> with no .eln already available).
>
> If this is the case is just `inhibit-automatic-native-compilation' not
> doing what it promises (read being broken).

It's meant to inhibit JIT compilation:

"If non-nil, inhibit automatic native compilation of loaded .elc files."

package.el calls the native-compilation functions directly, and are not
affected by the variable at all (as currently designed).

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

[Andrea Corallo]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>> Exactly.  I don't think magit is trying to invoke the native compiler
>> directly (I don't see any trace of that in magit's source code).  Also
>> other packages are reported to show the same issue (probably the one
>> with no .eln already available).
>>
>> If this is the case is just `inhibit-automatic-native-compilation' not
>> doing what it promises (read being broken).
>
> It's meant to inhibit JIT compilation:
>
> "If non-nil, inhibit automatic native compilation of loaded .elc files."
>
> package.el calls the native-compilation functions directly, and are not
> affected by the variable at all (as currently designed).

AFAIU this bug report is not about package.el, magit (again AFAIU) was
already installed.

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

[Lars Ingebrigtsen]

Andrea Corallo <akrl@sdf.org> writes:

> AFAIU this bug report is not about package.el, magit (again AFAIU) was
> already installed.

I'm not sure?

Max, could you (setq debug-on-error t) and repeat the problem and post
the resulting backtrace?

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

[Max Brieiev]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>> AFAIU this bug report is not about package.el, magit (again AFAIU) was
>> already installed.
>
> I'm not sure?
>
> Max, could you (setq debug-on-error t) and repeat the problem and post
> the resulting backtrace?

Here it is:

Debugger entered--Lisp error: (native-compiler-error (lambda (&rest arg1) (let ((f #'make-process)) (apply f arg1))) "Compiling /tmp/comp-lambda-TGVcD2.eln...\nx86_64-un...")
  (signal native-compiler-error ((lambda (&rest arg1) (let ((f #'make-process)) (apply f arg1))) "Compiling /tmp/comp-lambda-TGVcD2.eln...\nx86_64-un..."))
  (comp--native-compile (lambda (&rest arg1) (let ((f #'make-process)) (apply f arg1))) nil nil)
  (comp-trampoline-compile make-process)
  (comp-subr-trampoline-install make-process)
  (advice--add-function :around (#f(compiled-function () #<bytecode 0x3647c019df7e91>) . #f(compiled-function (gv--val) #<bytecode 0x85c60bbba7cb3c2>)) make-process--with-editor-process-filter nil)
  (advice-add make-process :around make-process--with-editor-process-filter)
  (require with-editor)
  (load-with-code-conversion "/home/max/.emacs.d/elpa/magit-20221008.1927/magit-process.el" "/home/max/.emacs.d/elpa/magit-20221008.1927/magit-process.el" nil t)
  (require magit-process)
  (load-with-code-conversion "/home/max/.emacs.d/elpa/magit-20221008.1927/magit-transient.el" "/home/max/.emacs.d/elpa/magit-20221008.1927/magit-transient.el" nil t)
  (require magit-transient)
  (load-with-code-conversion "/home/max/.emacs.d/elpa/magit-20221008.1927/magit-margin.el" "/home/max/.emacs.d/elpa/magit-20221008.1927/magit-margin.el" nil t)
  (require magit-margin)
  (load-with-code-conversion "/home/max/.emacs.d/elpa/magit-20221008.1927/magit-core.el" "/home/max/.emacs.d/elpa/magit-20221008.1927/magit-core.el" nil t)
  (require magit-core)
  (load-with-code-conversion "/home/max/.emacs.d/elpa/magit-20221008.1927/magit.el" "/home/max/.emacs.d/elpa/magit-20221008.1927/magit.el" nil t)
  (require magit)
  (load-with-code-conversion "/home/max/.emacs.d/elpa/magit-20221008.1927/magit-status.el" "/home/max/.emacs.d/elpa/magit-20221008.1927/magit-status.el" nil t)
  (command-execute magit record)
  (execute-extended-command nil "magit" "magit")
  (funcall-interactively execute-extended-command nil "magit" "magit")
  (command-execute execute-extended-command)

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

[Lars Ingebrigtsen]

Max Brieiev <max.brieiev@gmail.com> writes:

>   (comp--native-compile (lambda (&rest arg1) (let ((f #'make-process))
> (apply f arg1))) nil nil)
>   (comp-trampoline-compile make-process)

Oh, it's making trampolines.

inhibit-automatic-native-compilation does not inhibit making those, as
the manual explains:

     While setting this variable disables automatic compilation of Lisp
     files, the compiler may still be invoked to install “trampolines”
     if any built-in functions are redefined.  However, these
     trampolines will not get written to disk.

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

[Max Brieiev]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Max Brieiev <max.brieiev@gmail.com> writes:
>
>>   (comp--native-compile (lambda (&rest arg1) (let ((f #'make-process))
>> (apply f arg1))) nil nil)
>>   (comp-trampoline-compile make-process)
>
> Oh, it's making trampolines.
>
> inhibit-automatic-native-compilation does not inhibit making those, as
> the manual explains:
>
>      While setting this variable disables automatic compilation of Lisp
>      files, the compiler may still be invoked to install “trampolines”
>      if any built-in functions are redefined.  However, these
>      trampolines will not get written to disk.

Then this works as expected and the ticket can be closed.

I was confused by the part that says that trampolines (whatever the term
means) "will not get written to disk", but the error was about not being
able to create '.eln' file on disk.

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

[Lars Ingebrigtsen]

Max Brieiev <max.brieiev@gmail.com> writes:

> I was confused by the part that says that trampolines (whatever the term
> means) "will not get written to disk", but the error was about not being
> able to create '.eln' file on disk.

I've now clarified this a bit in the manual, and I'm closing this bug
report, then.

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

[Eli Zaretskii]

> Cc: 58429@debbugs.gnu.org, Andrea Corallo <akrl@sdf.org>
> From: Max Brieiev <max.brieiev@gmail.com>
> Date: Wed, 12 Oct 2022 14:57:20 +0300
> 
> I was confused by the part that says that trampolines (whatever the term
> means) "will not get written to disk", but the error was about not being
> able to create '.eln' file on disk.

Where do you see a message saying that the error is about creating the
file on disk?  The error message you quoted was different:

  x86_64-unknown-linux-gnu-gcc-10.3.0: fatal error: cannot execute ‘as’: execvp: No such file or directory

This says that the compilation tried to invoke 'as', the assembler,
but didn't find the assembler program file on your system.

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

[Max Brieiev]

Eli Zaretskii <eliz@gnu.org> writes:

> Where do you see a message saying that the error is about creating the
> file on disk?  The error message you quoted was different:
>
>   x86_64-unknown-linux-gnu-gcc-10.3.0: fatal error: cannot execute ‘as’: execvp: No such file or directory
>

But it also says:

    Compiling /tmp/comp-lambda-RCGJQI.eln

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

[Eli Zaretskii]

> From: Max Brieiev <max.brieiev@gmail.com>
> Cc: larsi@gnus.org,  58429@debbugs.gnu.org,  akrl@sdf.org
> Date: Wed, 12 Oct 2022 17:11:14 +0300
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Where do you see a message saying that the error is about creating the
> > file on disk?  The error message you quoted was different:
> >
> >   x86_64-unknown-linux-gnu-gcc-10.3.0: fatal error: cannot execute ‘as’: execvp: No such file or directory
> >
> 
> But it also says:
> 
>     Compiling /tmp/comp-lambda-RCGJQI.eln

Yes, but that's not an error message, that's an announcement of what
Emacs tries to do.

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

[Max Brieiev]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Max Brieiev <max.brieiev@gmail.com>
>> Cc: larsi@gnus.org,  58429@debbugs.gnu.org,  akrl@sdf.org
>> Date: Wed, 12 Oct 2022 17:11:14 +0300
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Where do you see a message saying that the error is about creating the
>> > file on disk?  The error message you quoted was different:
>> >
>> >   x86_64-unknown-linux-gnu-gcc-10.3.0: fatal error: cannot execute ‘as’: execvp: No such file or directory
>> >
>> 
>> But it also says:
>> 
>>     Compiling /tmp/comp-lambda-RCGJQI.eln
>
> Yes, but that's not an error message, that's an announcement of what
> Emacs tries to do.

Right, and the question was whether this was the correct behaviour for
Emacs to try to produce eln files, when
inhibit-automatic-native-compilation was non-nil.

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

[Eli Zaretskii]

> From: Max Brieiev <max.brieiev@gmail.com>
> Cc: larsi@gnus.org,  58429@debbugs.gnu.org,  akrl@sdf.org
> Date: Wed, 12 Oct 2022 19:54:00 +0300
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Max Brieiev <max.brieiev@gmail.com>
> >> Cc: larsi@gnus.org,  58429@debbugs.gnu.org,  akrl@sdf.org
> >> Date: Wed, 12 Oct 2022 17:11:14 +0300
> >> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> > Where do you see a message saying that the error is about creating the
> >> > file on disk?  The error message you quoted was different:
> >> >
> >> >   x86_64-unknown-linux-gnu-gcc-10.3.0: fatal error: cannot execute ‘as’: execvp: No such file or directory
> >> >
> >> 
> >> But it also says:
> >> 
> >>     Compiling /tmp/comp-lambda-RCGJQI.eln
> >
> > Yes, but that's not an error message, that's an announcement of what
> > Emacs tries to do.
> 
> Right, and the question was whether this was the correct behaviour for
> Emacs to try to produce eln files, when
> inhibit-automatic-native-compilation was non-nil.

Yes, it is.  When you use some Lisp that advises primitives, Emacs
with native-compilation must generate a trampoline, and
inhibit-automatic-native-compilation cannot prevent that.

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

[Andrea Corallo]

Max Brieiev <max.brieiev@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Max Brieiev <max.brieiev@gmail.com>
>>> Cc: larsi@gnus.org,  58429@debbugs.gnu.org,  akrl@sdf.org
>>> Date: Wed, 12 Oct 2022 17:11:14 +0300
>>> 
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>> 
>>> > Where do you see a message saying that the error is about creating the
>>> > file on disk?  The error message you quoted was different:
>>> >
>>> >   x86_64-unknown-linux-gnu-gcc-10.3.0: fatal error: cannot execute ‘as’: execvp: No such file or directory
>>> >
>>> 
>>> But it also says:
>>> 
>>>     Compiling /tmp/comp-lambda-RCGJQI.eln
>>
>> Yes, but that's not an error message, that's an announcement of what
>> Emacs tries to do.
>
> Right, and the question was whether this was the correct behaviour for
> Emacs to try to produce eln files, when
> inhibit-automatic-native-compilation was non-nil.

As Eli mentioned unfortunately we cannot disable trampolines.

But you are absolutely right, for a variable with such a name this
behavior is totally unexpectedle by the user.  I signaled that last week
(with no results) and indeed this is only the first of other bugs
reports we will get for this.

I've been explained this change is in master "for discussion" so I still
hope it will be reverted.

  Andrea

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

[Eli Zaretskii]

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

Am I confused about something here?

Thanks.

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

[Andrea Corallo]

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

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.

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

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

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

Thanks