Re: Safety of elisp-flymake-byte-compile (Was Re: [Emacs-diffs] scratch/allow-custom-load-paths)

["João Távora" <joaotavora@gmail.com>]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> 1. Create a elisp-flymake-maybe-enable function that checks the buffer
>>    for top-level forms that _could_ make it unsafe for byte-compiling on
>>    the fly.  This would include, but not limited to, eval-and-compile,
>>    eval-when-compile, defmacro, cl-defmacro, any "unknown" top-level
>>    form.  This will generate a lot of false positives (positive meaning
>>    "unsafe") but perhaps it could be made to generate 0 false negatives
>>    and still successfully vet a good number of elisp files.
>
> I was thinking that we can probably do it without a separate check:

You mean do it directly in elisp-flymake--batch-compile-for-flymake?
Yeah, that's definitely a good idea.

> In bytecomp.el, when working in "flymake" mode (a mode in which the
> output bytecode is not actually needed) we'd treat eval-when/and-compile
> just like `progn`, and we'd mark some other macros as "unsafe"
> (in which case we'd treat the corresponding calls as if they expanded
> to nil) and when we see a defmacro, we use `unsafep` to decide whether
> that macro should be treated as unsafe

Trying to parse this... You mean when we see a call to a macro, not when
we see a `defmacro' top-level form, right?

> (so we could still macro expand
> locally defined macros as long as they're simple enough).

> Also, in that mode, we'd likely skip byte-opt altogether as well as
> compiler macros.

OK. What's byte-opt BTW? Optimization?  

> The most obvious remaining holes there would be macros defined by
> installed packages and whose expansion includes execution of some of its
> arguments (cl-eval-when being the most obvious one, but there are many
> more subtle ones).

So basically, in your proposal, package authors would use sth. like
(declare (flymake-safe t)) in their defmacros?  But then we would have
to prompt the user to accept or reject these marks right?

I don't think I completely understood your idea: what about, for
example, eglot.el's macrology that checks LSP interface destructuring at
compile-time?  There are some eval-when-compile's there right now:

  (eval-and-compile
    (defvar eglot--lsp-interface-alist
      `(
        (CodeAction (:title) (:kind :diagnostics :edit :command))
        (Command (:title :command) (:arguments))
        ...)
        "Alist of (INTERFACE REQUIRED-KEYS OPTIONAL-KEYS)"))

And then

   (eglot--dbind ((Command) title not-really-a-key) some-lsp-object
     (do-something-with title not-really-a-key))

gives me a nice warning that not-really-a-key isn't in the "Command"
interface.  How would that work in your new elisp-flymake-byte-compile?

Also, what do you think of my option 2 to disable most of the system
interface when flymaking?

João