bug#45854: 28.0.50; [feature/native-comp] autoload behavior different in the presence of errors

[Andrea Corallo]

Mauricio Collares <mauricio@collares.org> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>> Here I'm,
>>
>> I can see the same exact behavior on current master as on a native-comp
>> build so I believe this is not a misbehavior.  I did the two experiments
>> starting from a clean .emacs.d to avoid state issues.
>
> Hi Andrea,
>
> Yes, I now agree. Starting with "HOME=~/tmp", a git bisect says that
> master changed behaviour at 9973019764250ac1f4d77a6b426cdd9c241151c5
> too. So this is not a problem with native-compilation and the bug I
> reported is invalid. Truly sorry for the confusion. I took care to
> delete ~/.emacs.d/elpa and the eln-cache directories between tests but
> there must be additional state that interfered with my initial testing.

No problem.

> I have one last question to ask you. The original investigation started
> because failure to compile a trampoline (due to an empty
> comp-eln-load-path, say) previously didn't interrupt package
> installation, and after changes on master it now does. So the remaining
> question is: Is triggering trampoline compilation expected even when
> running emacs non-interactively in a context (such as in the above
> testcase with an uncommented (provide 'transientx)) that otherwise does
> not generate .eln files? If this is the intended behaviour, would it
> make sense to make trampoline compilation failure emit a warning instead
> of an error in those contexts?

A trampoline is requested each time a primitive function gets redefined
or advised, if this is not available it gets synthesized.  Each eln
might make use of this, not only the one being compiled or installed
therfore is mandatory to have in interactive sessions as well as in non
interactive.  If we cannot satisfy this condition for any reason I think
is correct to have an error as Emacs might misbehave.

I'm not sure about what's going on in this specific case but if the
trampoline is requested means a primitive is being redefined or advised.

Okay I'm closing this bug.

Thanks

  Andrea