bug#53497: 29.0.50; native-compile after restarting Emacs

[Andrea Corallo <akrl@sdf.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arash Esbati <arash@gnu.org>
>> Cc: akrl@sdf.org,  larsi@gnus.org,  53497@debbugs.gnu.org
>> Date: Wed, 26 Jan 2022 12:25:43 +0100
>>
>>   /* This is so deferred compilation is able to compile comp
>>      dependencies breaking circularity.  */
>>   if (comp__loadable)
>>     {
>>       /* Startup is done, comp is usable.  */
>>       Frequire (Qcomp, Qnil, Qnil);
>>       Fputhash (function_name, definition, Vcomp_deferred_pending_h);
>>       CALLN (Ffuncall, intern_c_string ("native--compile-async"),
>> 	     src, Qnil, Qlate);
>>     }
>>   else
>>     Vcomp__delayed_sources = Fcons (src, Vcomp__delayed_sources);
>>
>> > Does one of these early returns indeed happen?
>>
>> No, early returns don't happen, but if (comp__loadable) goes into the
>> else part.  This is the part in GDB with Emacs b373c8ad71:
>
> Andrea, can you explain how this is supposed to work?  comp--loadable
> is set in startup.el, provided that comp--delayed-sources is non-nil,
> but which code is supposed to put something into comp--delayed-sources
> by the time we call startup--honor-delayed-native-compilations during
> startup?

Before `comp--loadable' becomes true (read the native compiler is not
loadable) each time we enter in 'maybe_defer_native_compilation' we
accumulate the compilation units we want to compile in
`comp--delayed-sources'.

When we finally call `startup--honor-delayed-native-compilations' we
check if something is pending in `comp--delayed-sources' and if this is
the case we load the native compiler and we compile what's pending.

Unless I'm wrong the problem I see here is that if
`comp--delayed-sources' is empty we never set `comp--loadable' to t.
I'll be testing a patch today and report.

  Andrea