Subject: bug#57627: 29.0.50; [native-compilation] cl-loaddefs.el recompiled on startup

From: Lars Ingebrigtsen <[email-masked]>
Date: Sat, 15 Oct 2022 12:13:32 +0200

Stefan Monnier <[email-masked]> writes:

> After spending many milliseconds thinking about it, my conclusion is
> that the bytecompiler should add a little code snippet like
> (puthash load-file-name t comp--no-native-compile) in the
> file if `no-native-compile` was specified.  So it then be easy for the
> lazy native compilation to detect that it should skip this file (since
> lazy native compilation is triggered after loading the file) by just
> consulting `comp--no-native-compile`.
>
> For that, there's no need to change the way `no-native-compile` is specified.

True, but it's kinda hacky, and if possible, I'd like to avoid adding
more hacks in this area...

>> That is, in this case, we'd say
>>
>> (pragma 'no-native-compile)
>>
>> somewhere in the file.
>
> I guess that could work for `no-native-compile`, indeed.  But if you ask
> to native compile this file and the pragma is halfway down the file,
> what happens?

Yes, that's no good.  Uhm...  we could make a rule that all `pragma's
have to appear as the first form(s) in a Lisp file?  And error out if
somebody tries to add a `pragma' later in the file.

I think that would make sense in general -- we're trying to express
something about the file as a whole, after all.

>> We could have
>>
>> (pragma 'dynamic-binding)
>
> I guess this one could work (of course, it'd have to be at top-level),
> and we could switch back&forth within the same file (yuck!).
>
> But if we allow such `pragma` to be output by macros, then it becomes
> tricky for `eval-region` to reliably decide which dialect to use.

Hm, yes...  But we have the same issue today, don't we?  That is

(progn
  (pop-to-buffer "*foo*")
  (emacs-lisp-mode)
  (insert ";;;  -*- lexical-binding: t -*-\n(message \"Lex: %s\" lexical-binding)")
  (eval-region (pos-bol) (point)))

Well, OK, that's the same result with point-min, but...

> So we could allow such `pragma`, but we'd likely end up restricting its
> syntax so we're able to find it with something like a regexp search, so
> in the end it's not clear what's the advantage over
> file-local variables.

If they have to be the first forms, there may be some advantages...