Re: Finalizing 'inhibit-automatic-native-compilation'

[Lynn Winebarger]

On Mon, Feb 6, 2023 at 10:28 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Lynn Winebarger <owinebar@gmail.com>
> > Date: Mon, 6 Feb 2023 09:29:10 -0500
> > Cc: Andrea Corallo <akrl@sdf.org>, Stefan Monnier 
> > <monnier@iro.umontreal.ca>,
> >       emacs-devel <emacs-devel@gnu.org>
> >
> >  No, I'm saying that starting Emacs assumes the dumped *.eln files live
> >  in one of two possible locations, and you must make sure they are in
> >  one of those two locations, or else Emacs will fail to start.
> >
> > Then I'm confused by what you mean by "re-dumping" above.  I'm only 
> > referencing the result of starting
> > temacs in dump-mode.
>
> You started the re-dumping subject (although the current discussion is
> about something completely different).
Not with regard to native-compiled libraries.  But to circle back to
your question about whether emacs 29 exhibited this behavior, this
discussion has clarified the disconnect in our understanding.

To answer your question, I need to construct some test cases with the
following property:
Library A containing function f which is  always invoked in the native
compiler process
Library B containing function g is used to advise function f
under 2 variants of the dump file
1) Library A is included in the dump used in the native compiler
process, but the ELN is not loaded prior to the dump
2) Library A is included in the dump used in the native compiler
process, and the ELN was loaded prior to the dump
and 3 variants in the way the advice is applied
a) In the ordinary eval phase of loading the library
b) In a compile-when-eval or compile-and-eval context
c) During macro expansion

A variant of these test cases would be when function f is only
conditionally invoked in the native compiler process.

I observed the behavior in question when "f" was "call-interactively"
with variant (2) of the dump file.  I don't know what library B or
function g was, or which of variants (a) - (c) was the case.  But it
should be possible to identify some other function f involved in the
native compiler process and a library B and function g under each of
those variants without having to be able to dump (e.g.) a
native-compiled cl-lib.

Another set of test cases would be those that are unlikely to arise by
accident, for example in which each B/g deliberately creates a novel
B'/g' that it native-compiles and requires during the trampoline
compiling process, so it couldn't be caught by simply tracking which
functions are being processed.

Lynn