[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Safety of elisp-flymake-byte-compile (Was Re: [Emacs-diffs] scratch/
From: |
João Távora |
Subject: |
Re: Safety of elisp-flymake-byte-compile (Was Re: [Emacs-diffs] scratch/allow-custom-load-paths) |
Date: |
Mon, 10 Dec 2018 00:20:39 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Stefan Monnier <address@hidden> 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
- Re: [Emacs-diffs] scratch/allow-custom-load-paths-in-elisp-flymake 4ef9711: Allow custom load paths in elisp's byte-compilation Flymake, Stefan Monnier, 2018/12/04
- Re: [Emacs-diffs] scratch/allow-custom-load-paths-in-elisp-flymake 4ef9711: Allow custom load paths in elisp's byte-compilation Flymake, João Távora, 2018/12/05
- Re: [Emacs-diffs] scratch/allow-custom-load-paths-in-elisp-flymake 4ef9711: Allow custom load paths in elisp's byte-compilation Flymake, Glenn Morris, 2018/12/05
- Re: [Emacs-diffs] scratch/allow-custom-load-paths-in-elisp-flymake 4ef9711: Allow custom load paths in elisp's byte-compilation Flymake, João Távora, 2018/12/05
- Safety of elisp-flymake-byte-compile (Was Re: [Emacs-diffs] scratch/allow-custom-load-paths), João Távora, 2018/12/08
- Re: Safety of elisp-flymake-byte-compile (Was Re: [Emacs-diffs] scratch/allow-custom-load-paths), Stefan Monnier, 2018/12/08
- Re: Safety of elisp-flymake-byte-compile (Was Re: [Emacs-diffs] scratch/allow-custom-load-paths),
João Távora <=
- Re: Safety of elisp-flymake-byte-compile (Was Re: [Emacs-diffs] scratch/allow-custom-load-paths), Stefan Monnier, 2018/12/09
- Re: Safety of elisp-flymake-byte-compile (Was Re: [Emacs-diffs] scratch/allow-custom-load-paths), João Távora, 2018/12/10
- Re: Safety of elisp-flymake-byte-compile (Was Re: [Emacs-diffs] scratch/allow-custom-load-paths), Stefan Monnier, 2018/12/11
- Re: Safety of elisp-flymake-byte-compile (Was Re: [Emacs-diffs] scratch/allow-custom-load-paths), João Távora, 2018/12/14
- Re: Safety of elisp-flymake-byte-compile (Was Re: [Emacs-diffs] scratch/allow-custom-load-paths), Stefan Monnier, 2018/12/14
- Re: Safety of elisp-flymake-byte-compile (Was Re: [Emacs-diffs] scratch/allow-custom-load-paths), João Távora, 2018/12/14
- Re: Safety of elisp-flymake-byte-compile (Was Re: [Emacs-diffs] scratch/allow-custom-load-paths), Stefan Monnier, 2018/12/14
- Re: Safety of elisp-flymake-byte-compile (Was Re: [Emacs-diffs] scratch/allow-custom-load-paths), João Távora, 2018/12/14
- Re: Safety of elisp-flymake-byte-compile (Was Re: [Emacs-diffs] scratch/allow-custom-load-paths), Stefan Monnier, 2018/12/14
- Sandboxing (was: Safety of elisp-flymake-byte-compile), Stefan Monnier, 2018/12/11