bug#63871: 29.0.91; JIT native comp triggered to compile loaddefs repeatedly on require

[Jimmy Wong]

The problem is this:

1. There’s no-native-compile:r set in the file, so a eln file was never produced.
2. nativecomp does not know which file should not be compiled until it opens the file
3. Whenever a require is encountered, nativecomp can’t find its eln, doesn’t know it can’t be compiled until it reads the file, and it can’t read the file until it unzips the file.
4. This unnecessary work is done every time any package requires one of these packages that cannot be compiled, again and again, generating an extra buffer that mess up the buffer orders in the buffer list.

On 3 Jun 2023 at 2:50 PM +0100, Eli Zaretskii <eliz@gnu.org>, wrote:

From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
Date: Sat, 03 Jun 2023 14:22:41 +0100


Reproduction:

1. emacs -q -nsl --eval="(require 'cl-lib)"
2. C-x b TAB
3. Select *Async-native-compile-log*
4. The following is printed

```emacs-lisp
Compiling /opt/local/share/emacs/29.0.91/lisp/emacs-lisp/cl-loaddefs.el.gz...
uncompressing cl-loaddefs.el.gz...
uncompressing cl-loaddefs.el.gz...done
Compilation finished.
```

Expectation:

This behavior is observed when any packages in ~/.emacs.d/elpa/
autoloads and require cl-lib, org or tramp as well.

The simple act of requiring a built-in Emacs package should not trigger
a JIT native compilation on an Emacs installation built with
`--with-native-compilation=aot`.

And it doesn't. cl-loaddefs has the "no-native-compile: t" thingy in
the file-local variables, so the native-compilation does nothing.

So I don't see any bug here, and I'm closing this bug.