bug#23648: [PATCH] `defun-declarations-alist' can be unintentionally modified

[Noam Postavsky]

On Thu, Jul 21, 2016 at 10:22 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> Thanks, but I think we are mis-communicating.  What I need is not a
> demonstration of the bug in action; I already got that.  What I asked
> for is different:
>
>> How probable is the situation where this problem pops up?  And when
>> was the bug introduced?
>
> You already answered the second question.  For the first, I expected
> to see something done frequently by either users or Lisp programs,
> which bumps into this bug.  Evaluating macroexpand, twice, with
> completion in-between, doesn't qualify in my book as a frequent user
> action, I hope you will agree (even if you personally happen to use it
> quite a lot).
>
> So I'm still looking for the answer to the "how probable" question.  I
> need that to make up my mind about the urgency of the fix.

Ah, okay. The probability of a user hitting this depends on how likely
they are to perform completion inside a declare form. This depends on
the kind of code the user writes, so it's hard to put a number on it.
Also, if the user has a package like company enabled that performs
completion during idle time, then just moving point through a declare
form should be enough to trigger it, so in this case it might depend
also on the kind of code the user reads. If the user never opens an
elisp file with declare forms, then they certainly won't hit this.

Once the user has triggered the problem via completion, all
compilation of defuns (e.g. during package installation/upgrade) with
declare forms will be broken (as well as loading uncompiled defuns
with declare forms). Admittedly only gv-expander (along with
gv-setter, but that one doesn't get unlearned) is vital to correct
compilation, the rest (advertised-calling-convention obsolete
interactive-only pure side-effect-free compiler-macro doc-string
indent) are only optimizations or advisory in nature.