bug#61880: Native compilation fails to generate trampolines on certain scenarios

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: Sergio Durigan Junior <sergiodj@sergiodj.net>,  61880@debbugs.gnu.org
> Date: Fri, 03 Mar 2023 10:05:21 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Emitting such a warning for every primitive that is redefined or
> > advised could be annoying indeed, but maybe we should warn only about
> > the few primitives that might disrupt compilation of trampolines, and
> > only when a trampoline is compiled?  Andrea, can we do something like
> > that?
> >
> 
> I think technically should be easy to emit the warning, again the non
> trivial part is to form the list of primitives to warn at redefinition
> (and to keep this list updated over time!).

Well, currently we don't warn at all, so even warning about some of
the primitives would be an improvement, I think.

> To a quick look into the trampoline machinery in comp.el I see we rely
> on:
> 
> null, memq, gethash, and, subrp, not, subr-native-elisp-p,
> comp--install-trampoline, concat, if, symbolp, symbol-name, make-string,
> length, aset, aref, length>, mapcar, expand-file-name,
> file-name-as-directory, file-exists-p, native-elisp-load.
> 
> Note: I haven't followed all the possible execution paths outside
> comp.el.
> 
> Should we start with these?

Yes, I think we should start with those, and add more as we discover
them.

> PS I'll never understand why people think redefining something like `if'
> would indeed break everything but they expect `file-exists-p' to be
> redefinable at any point

I agree.  But since we are going to have a list of primitives to warn
about anyway, I see no reason not to have those basic ones there, just
in case someone tries to do the unimaginable, for whatever reasons.

Thanks.