bug#43725: 28.0.50; Include feature/native-comp into master

[Andrea Corallo]

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

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Andrea Corallo <akrl@sdf.org>
>>> Cc: larsi@gnus.org, monnier@iro.umontreal.ca, 43725@debbugs.gnu.org
>>> Date: Wed, 10 Mar 2021 15:45:49 +0000
>>> 
>>> this is not expected and I cannot reproduce it here.
>>
>> OK, so just to be sure we are taking about the same scenario:
>>
>>   . I touch comp.el while a comp-NNNNN.eln already exists in
>>     ~/.emacs.d/eln-cache.
>>   . I then start "emacs -Q" and invoke "C-h f" for some function whose
>>     .el file doesn't yet have a .eln file.  For example,
>>
>>         C-h f ruler-mode RET
>>
>>   . What I see next is that Emacs starts compiling in the background,
>>     and I later find that both ruler-mode.el and comp.el have been
>>     natively-compiled.
>>
>> Hmmm... now I see that it doesn't happen every time.  So I guess some
>> additional factor is at work here, indeed.
>>
>>> The file is hashed using the content + its filename so access and
>>> modification times should not come into play.  Are we sure the file
>>> content wasn't modified?
>>
>> The file wasn't modified, that's for sure.
>>
>>> Or we might be possibly looking at different issue here.
>>
>> Probably.  I'll try to step through the code, but could you give me
>> some pointers: where do we decide whether to native-compile a file
>> that we load?
>
> The triggering point we are interested in here should be
> 'maybe_defer_native_compilation' (called by 'Fdefalias').

Sorry thinking about I believe for this case would be more interesting
to see why 'maybe_swap_for_eln' is failing to find the corresponding
.eln.  This is called in 'openp'.

Thanks

  Andrea