bug#46617: 28.0.50; nativecomp: native compile cache is not invalidated when file is re-byte compiled and changes

[Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Aaron Jensen <aaronjensen@gmail.com> writes:

> On Thu, Feb 25, 2021 at 3:04 AM Andrea Corallo <akrl@sdf.org> wrote:
>>
>> Even tho I've no precise analysis on this most likely this is related to
>> the fact that I broke async compilation with 81b1013555 and fixed it
>> with 0ee1a16769.
>>
>> Right I'm closing this (we can always reopen in case).
>
> Ah, I'm afraid we have to reopen. What you describe was the reason it
> didn't repro for me this last time. It still does currently.

Hi Aaron,

I had to slightly modify your init.el reproducer as we have changed the
semantic of `load' [1].

init.el:
=========
(let ((repro
       (expand-file-name "repro.el" default-directory)))
  (defun some-fn ()
    1)
  (message "Byte and native compiling, some-fn = 1")
  (byte-compile-file repro)
  (load (native-compile repro))

  (message "Byte compiling, some-fn = 2")
  (defun some-fn ()
    2)
  (byte-compile-file repro)
  (load (concat repro "c") nil 'nomessage 'nosuffix)

  (message "Native compiling, some-fn = 2")
  (load (native-compile repro)))
=========

This is still:

- defining `some-fn'
- native compiling and loading repro.el
- re-defining `some-fn'
- byte compiling and loading repro.el
- native compiling and loading repro.el

Running ./src/emacs -Q -l init.el in the *Messages* buffer I get:

=========
Byte and native compiling, some-fn = 1
Compiling /home/andcor03/emacs2/repro.el...done
Wrote /home/andcor03/emacs2/repro.elc
Compiling /home/andcor03/emacs2/repro.el...done
Loading /home/andcor03/.emacs.d/eln-cache/28.0.50-32137a9a/repro-fd364f11-b5afb0b4.eln (native compiled elisp)...
EQUAL
Loading /home/andcor03/.emacs.d/eln-cache/28.0.50-32137a9a/repro-fd364f11-b5afb0b4.eln (native compiled elisp)...done
Byte compiling, some-fn = 2
Compiling /home/andcor03/emacs2/repro.el...done
Wrote /home/andcor03/emacs2/repro.elc
EQUAL
Native compiling, some-fn = 2
Compiling /home/andcor03/emacs2/repro.el...done
Loading /home/andcor03/.emacs.d/eln-cache/28.0.50-32137a9a/repro-fd364f11-b5afb0b4.eln (native compiled elisp)...
EQUAL
Loading /home/andcor03/.emacs.d/eln-cache/28.0.50-32137a9a/repro-fd364f11-b5afb0b4.eln (native compiled elisp)...done
=========

I think what happened is that in the original reproducer the second load
of the .elc file still automatically loaded in place the corresponding
.eln as the source file didn't changed.  The issue here is that in the
compilation unit repro.elk is capturing some of the environment and this
is not accounted in the hash computation of the .eln file.

The new reproducer (well it does not reproduce much :) ) works because
now `load' called explicitly on a .elc file does not load automatically
the corresponding .eln.  Alternatively to overcome the issue still using
native compilation one has to force a new native compilation using
`native-compile.  WDYT?

Thanks

  Andrea

[1] <https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-03/msg01643.html>