Make the tests work reliably with native compilation enabled

I am the maintainer of projectile for debian. (Aymeric Agon-Rambosson)

As part of the building process of our packages, we run the tests
provided by the upstream maintainers in a clean and empty
environment (no writable $HOME, no internet access, etc...). For
this reason, we sometimes uncover bugs that would remain masked on
the machines of the upstream maintainers, and of the users.

The test "projectile-parse-dirconfig-file" can break in a very
specific setting :

Since version 28.1, emacs has been shipped with
native-compilation, that is the possibility to compile elisp to
native instructions using libgccjit. Since elisp allows the
advising of functions implemented in C ("primitives"), it is
necessary to compile trampolines to replace those functions if we
want to advise them, in order to allow an arbitrary user-defined
function to be run instead.

The test library you use, buttercup, and more specifically its
function spy-on, advises functions routinely.

In the test we're interested in, buttercup (spy-on) changes the
definition of a few primitives in the offending test
(projectile-parse-dirconfig-file), namely file-exists-p,
file-truename and insert-file-contents.

The first one is advised so as to always return t, regardless of
whether the file is really present or not.

The first two are advised without error. The last one, however,
can fail because, being a primitive, a trampoline needs to be
compiled. We have the following backtrace in our build environment
:

comp-subr-trampoline-install(insert-file-contents)
comp-trampoline-search(insert-file-contents)
native-elisp-load("/tmp/buttercupKuLmvD/28.2-4001e2a9/subr--trampoline-696...
error: (native-lisp-load-failed "file does not exists"
"/tmp/buttercupKuLmvD/28.2-4001e2a9/subr--trampoline-696e736572742d66696c652d636f6e74656e7473_insert_file_contents_0.eln")

What happens here is the following : if we are in a situation
where the trampoline corresponding to the function
insert-file-contents is not already present in some eln-cache
directory on the machine, then the function comp-trampoline-search
should return nil, which would trigger the compilation of said
trampoline.

However, since comp-trampoline-search relies on file-exists-p, and
this last one has been advised so as to always answer yes,
comp-trampoline-search tries to load a file that does not exists,
hence our error.

You or your users probably never reach that state, probably
because you can always count on the trampoline being present
beforehand. But if it is not there, you should be able to
reproduce. We always reach that state because we run the tests in
a clean environment, where the trampoline is never present.

This error can be expected whenever a primitive is advised (in our
case insert-file-contents) while file-exists-p is already advised
so as to always return t, and the trampoline corresponding to the
primitive does not already exists on the file system.

There are two possible solutions : the first one is to try and
ensure the trampoline is present by the time of the advice, for
instance by compiling it unconditionally before the test. This is
not entirely reliable, as some environments could inhibit the
saving of this trampoline to the file system (this is what we do,
for instance).

The second one is to exclude the function insert-file-contents
(and indeed, any primitive you would want to advise while
file-exists-p is advised as to always return t) from trampoline
optimisation completely. The variable
native-comp-never-optimize-functions can be used to do just that.
This patch tweaks it accordingly.

test/projectile-test.el

@@ -26,6 +26,11 @@
 
 ;;; Code:
 
+;; needed for the tests to work with native compilation
+(with-eval-after-load 'comp
+  (push 'insert-file-contents
+        native-comp-never-optimize-functions))
+
 (require 'projectile)
 (require 'buttercup)