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

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> 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:
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 (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.

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).


        Stefan