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

[Eli Zaretskii]

> From: Sergio Durigan Junior <sergiodj@sergiodj.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  61880@debbugs.gnu.org
> Date: Wed, 01 Mar 2023 18:14:01 -0500
> 
> > I don't think there is a trivial fix for this, we should rewrite
> > `comp-trampoline-search' in C in order to have it not sensitive to the
> > redefinition of `file-exists-p', or define another primitive like
> > `comp-file-exists-p' (that calls directly Ffile_exists_p from C) and use
> > that in `comp-trampoline-search'.  This would cover this specific case
> > but potentially not others.
> 
> Forgive my ignorance, but wouldn't we need to do that for every
> primitive that can be compiled into a trampoline?

That's basically what Andrea was saying by the "potentially not
others" part.  So you are in agreement here.

> > Fact is, Emacs can't be robust against the redefinition of all
> > primitives (actually never was), the programmer that redefines
> > primitives should be ready to understand the underlying Emacs machinery,
> > and with native compilation this machinery changed a bit.
> 
> I understand where you're coming from, but it's also important to note
> that this behaviour was accepted without problems until the native
> compilation feature came about, so it is understandable that we are
> getting a lot of confusing people wondering why their tests started
> failing now.  I believe there should be more emphasis in the
> documentation that this problem can creep in, especially for those who
> are relying on redefinitions for testing purposes.
> 
> > So two options:
> >
> > * The redefinition of `file-exists-p' is tipically done for test
> >   purposes only, we accept that and for this case we suggest to run
> >   these specific tests setting `native-comp-enable-subr-trampolines' to
> >   nil
> 
> This is what I'm currently doing in Debian/Ubuntu, and will start
> suggesting upstream maintainers to do the same.

I can come up with documentation of this subtlety, including a list of
primitives whose redefinition could trigger these issues, if this is
an acceptable solution.

> > * We work around this specific issue with the `comp-file-exists-p' trick
> >   (or another one).
> 
> As said above, I don't believe this will be enough for this case, but I
> may be completely wrong here.

You are not wrong.  I don't think the 2nd alternative is what we
should do.