[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#64494: 30.0.50; Recursive load error with native-compile
From: |
Stefan Monnier |
Subject: |
bug#64494: 30.0.50; Recursive load error with native-compile |
Date: |
Fri, 07 Jul 2023 21:22:33 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
> There's another thing I don't quite understand about our code here: why
> do we call `native--compile-async` from `defalias` (via
> `maybe_defer_native_compilation`) rather than doing it from something
> like `after-load-functions`?
Hmm... I see that its not done for the "deferred compilation" but it's
done for the subsequent *reload* (which replaces the previously loaded
bytecode functions with their newly native-compiled version).
The problem being that we shouldn't load the .eln (and thus replace
the bytecode with native code) if the bytecode has been replaced with
something else in the mean time.
IOW, we need some way to detect when changes occur to the `.elc`-defined
functions between the time the `.elc` file is loaded and the time the
`.eln` file is available for load. This is done by storing the `.elc`
definitions in an auxiliary hash-table (`comp-deferred-pending-h`) so
they can be compared to the current definition before replacing it withe
new definition from`.eln`.
So, if we want to do it from `after-load-functions`, we need to use
`load-history` to collect all the definitions and populate
`comp-deferred-pending-h`.
Stefan