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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 23648 in the body.
You can then email your comments to 23648 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Pogonyshev <pogonyshev <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] `defun-declarations-alist' can be unintentionally modified
Date: Sun, 29 May 2016 16:11:02 +0200

[Message part 1 (text/plain, inline)]

I quite often get the following messages:

Warning: Unknown defun property ‘compiler-macro’ in ...

As far as I could trace it, the problem is indirectly caused by
`define-inline'. While definition of `defun-declarations-alist' does
contain `compiler-macro' in its init form, it can be removed later.
E.g. when I evaluated the variable, it was not there anymore, only
`gv-setter' was there.

It seems this is done unintentionally by `elisp-completion-at-point':

                       (`declare
                        (list t (mapcar (lambda (x) (symbol-name (car x)))
                                        (delete-dups
                                         ;; FIXME: We should include some
                                         ;; docstring with each entry.
                                         (append
                                          macro-declarations-alist
                                          defun-declarations-alist)))))

Here `delete-dups' destructively modifies a list that includes
`defun-declarations-alist' as its tail verbatim, not as a copy.
Attached patch should fix that.

Paul

* elisp-mode.el (elisp-completion-at-point): Fix to not alter
`defun-declarations-alist' by side effect.

[xxx.diff (text/plain, attachment)]

Message #8 received at 23648 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Paul Pogonyshev <pogonyshev <at> gmail.com>
Cc: 23648 <at> debbugs.gnu.org
Subject: Re: bug#23648: [PATCH] `defun-declarations-alist' can be
 unintentionally modified
Date: Sun, 17 Jul 2016 23:00:33 -0400

Paul Pogonyshev <pogonyshev <at> gmail.com> writes:

> I quite often get the following messages:
>
> Warning: Unknown defun property ‘compiler-macro’ in ...
>
> As far as I could trace it, the problem is indirectly caused by
> `define-inline'. While definition of `defun-declarations-alist' does
> contain `compiler-macro' in its init form, it can be removed later.
> E.g. when I evaluated the variable, it was not there anymore, only
> `gv-setter' was there.
>
> It seems this is done unintentionally by `elisp-completion-at-point':
>
>                        (`declare
>                         (list t (mapcar (lambda (x) (symbol-name (car x)))
>                                         (delete-dups
>                                          ;; FIXME: We should include some
>                                          ;; docstring with each entry.
>                                          (append
>                                           macro-declarations-alist
>                                           defun-declarations-alist)))))
>
> Here `delete-dups' destructively modifies a list that includes
> `defun-declarations-alist' as its tail verbatim, not as a copy.
> Attached patch should fix that.

I agree with analysis and patch here.  Since this just appends another
nil, it should be safe for emacs-25, right?

>
> Paul
>
> * elisp-mode.el (elisp-completion-at-point): Fix to not alter
> `defun-declarations-alist' by side effect.

> -                                         (append
> -                                          macro-declarations-alist
> -                                          defun-declarations-alist)))))
> +                                         (append macro-declarations-alist
> +                                                 defun-declarations-alist
> +                                                 nil)))))

Message #11 received at 23648 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: npostavs <at> users.sourceforge.net
Cc: 23648 <at> debbugs.gnu.org, pogonyshev <at> gmail.com
Subject: Re: bug#23648: [PATCH] `defun-declarations-alist' can be
 unintentionally modified
Date: Mon, 18 Jul 2016 17:33:27 +0300

> From: npostavs <at> users.sourceforge.net
> Date: Sun, 17 Jul 2016 23:00:33 -0400
> Cc: 23648 <at> debbugs.gnu.org
> 
> I agree with analysis and patch here.  Since this just appends another
> nil, it should be safe for emacs-25, right?

I'm not sure, actually.  How probable is the situation where this
problem pops up?  And when was the bug introduced?

Message #14 received at 23648 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23648 <at> debbugs.gnu.org, Paul Pogonyshev <pogonyshev <at> gmail.com>
Subject: Re: bug#23648: [PATCH] `defun-declarations-alist' can be
 unintentionally modified
Date: Mon, 18 Jul 2016 11:53:42 -0400

On Mon, Jul 18, 2016 at 10:33 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: npostavs <at> users.sourceforge.net
>> Date: Sun, 17 Jul 2016 23:00:33 -0400
>> Cc: 23648 <at> debbugs.gnu.org
>>
>> I agree with analysis and patch here.  Since this just appends another
>> nil, it should be safe for emacs-25, right?
>
> I'm not sure, actually.  How probable is the situation where this
> problem pops up?

It happens with 100% probability when performing completion inside a
(declare ...) form. Starting from emacs -Q, put into *scratch*

(defun foo ()
  (declare (indent 1))
  nil)

Macroexpanding this gives:

(prog1
    (defalias 'foo
      #'(lambda nil nil))
  (put 'foo 'lisp-indent-function '1))

Now move point to just after "indent" and type C-M-i (this gives
message "Sole completion"), macroexpanding now gives

(prog1
    (defalias 'foo
      #'(lambda nil nil))
  "Warning: Unknown defun property `indent' in foo")

>  And when was the bug introduced?

Code seems to have been that way since it was introduced in 24.4:
dd8791e9 "* lisp/emacs-lisp/lisp.el (lisp-completion-at-point):
Provide specialized
completion tables when completing error conditions and
`declare' arguments...."

Message #17 received at 23648 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 23648 <at> debbugs.gnu.org, pogonyshev <at> gmail.com
Subject: Re: bug#23648: [PATCH] `defun-declarations-alist' can be
 unintentionally modified
Date: Mon, 18 Jul 2016 21:16:00 +0300

> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
> Date: Mon, 18 Jul 2016 11:53:42 -0400
> Cc: Paul Pogonyshev <pogonyshev <at> gmail.com>, 23648 <at> debbugs.gnu.org
> 
> > I'm not sure, actually.  How probable is the situation where this
> > problem pops up?
> 
> It happens with 100% probability when performing completion inside a
> (declare ...) form. Starting from emacs -Q, put into *scratch*
> 
> (defun foo ()
>   (declare (indent 1))
>   nil)
> 
> Macroexpanding this gives:
> 
> (prog1
>     (defalias 'foo
>       #'(lambda nil nil))
>   (put 'foo 'lisp-indent-function '1))
> 
> Now move point to just after "indent" and type C-M-i (this gives
> message "Sole completion"), macroexpanding now gives
> 
> (prog1
>     (defalias 'foo
>       #'(lambda nil nil))
>   "Warning: Unknown defun property `indent' in foo")

Sorry, I'm not following: what do you mean by "macroexpanding" in this
context?  When you wrote "when performing completion", I expected to
see some simple completion gesture that leads to an error, but it
sounds like I'm missing something.

> >  And when was the bug introduced?
> 
> Code seems to have been that way since it was introduced in 24.4:
> dd8791e9 "* lisp/emacs-lisp/lisp.el (lisp-completion-at-point):
> Provide specialized
> completion tables when completing error conditions and
> `declare' arguments...."

Thanks.

Message #20 received at 23648 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23648 <at> debbugs.gnu.org, Paul Pogonyshev <pogonyshev <at> gmail.com>
Subject: Re: bug#23648: [PATCH] `defun-declarations-alist' can be
 unintentionally modified
Date: Mon, 18 Jul 2016 14:58:20 -0400

On Mon, Jul 18, 2016 at 2:16 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
>> Date: Mon, 18 Jul 2016 11:53:42 -0400
>> Cc: Paul Pogonyshev <pogonyshev <at> gmail.com>, 23648 <at> debbugs.gnu.org
>>
>> > I'm not sure, actually.  How probable is the situation where this
>> > problem pops up?
>>
>> It happens with 100% probability when performing completion inside a
>> (declare ...) form. Starting from emacs -Q, put into *scratch*
>>
>> (defun foo ()
>>   (declare (indent 1))
>>   nil)
>>
>> Macroexpanding this gives:
>>
>> (prog1
>>     (defalias 'foo
>>       #'(lambda nil nil))
>>   (put 'foo 'lisp-indent-function '1))
>>
>> Now move point to just after "indent" and type C-M-i (this gives
>> message "Sole completion"), macroexpanding now gives
>>
>> (prog1
>>     (defalias 'foo
>>       #'(lambda nil nil))
>>   "Warning: Unknown defun property `indent' in foo")
>
> Sorry, I'm not following: what do you mean by "macroexpanding" in this
> context?

Calling macroexpand on the defun form. The most convenient method for
testing is to put point at the closing bracket of the defun, and then
`M-x pp-macroexpand-last-sexp'.

> When you wrote "when performing completion", I expected to
> see some simple completion gesture that leads to an error, but it
> sounds like I'm missing something.

The simple completion gesture would be the C-M-i I mentioned, which
(silently) destroys the value of defun-declarations-alist. The
symptoms of the wrong value can be seen when defun is macroexpanded.

Message #23 received at 23648 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 23648 <at> debbugs.gnu.org, pogonyshev <at> gmail.com
Subject: Re: bug#23648: [PATCH] `defun-declarations-alist' can be
 unintentionally modified
Date: Mon, 18 Jul 2016 22:08:49 +0300

> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
> Date: Mon, 18 Jul 2016 14:58:20 -0400
> Cc: Paul Pogonyshev <pogonyshev <at> gmail.com>, 23648 <at> debbugs.gnu.org
> 
> >> Now move point to just after "indent" and type C-M-i (this gives
> >> message "Sole completion"), macroexpanding now gives
> >>
> >> (prog1
> >>     (defalias 'foo
> >>       #'(lambda nil nil))
> >>   "Warning: Unknown defun property `indent' in foo")
> >
> > Sorry, I'm not following: what do you mean by "macroexpanding" in this
> > context?
> 
> Calling macroexpand on the defun form. The most convenient method for
> testing is to put point at the closing bracket of the defun, and then
> `M-x pp-macroexpand-last-sexp'.
> 
> > When you wrote "when performing completion", I expected to
> > see some simple completion gesture that leads to an error, but it
> > sounds like I'm missing something.
> 
> The simple completion gesture would be the C-M-i I mentioned, which
> (silently) destroys the value of defun-declarations-alist. The
> symptoms of the wrong value can be seen when defun is macroexpanded.

Sorry, I guess I'm too stupid to understand this advanced stuff.  Or
maybe it's too late.

Thanks.

Message #26 received at 23648 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: npostavs <at> users.sourceforge.net, Paul Pogonyshev <pogonyshev <at> gmail.com>
Cc: 23648 <at> debbugs.gnu.org
Subject: Re: bug#23648: [PATCH] `defun-declarations-alist' can be
 unintentionally modified
Date: Mon, 18 Jul 2016 22:17:56 +0300

On 07/18/2016 06:00 AM, npostavs <at> users.sourceforge.net wrote:

>> Here `delete-dups' destructively modifies a list that includes
>> `defun-declarations-alist' as its tail verbatim, not as a copy.
>> Attached patch should fix that.
>
> I agree with analysis and patch here.

I like the patch as well. Maybe it would be better to use 
cl-remove-duplicates with nconc instead (the use of nil is a little 
non-obvious), but that would require having cl-lib loaded at runtime, 
and elisp-mode depending on it.

In any case, the proposed patch looks safe.

Message #29 received at 23648 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23648 <at> debbugs.gnu.org, pogonyshev <at> gmail.com,
 Noam Postavsky <npostavs <at> users.sourceforge.net>
Subject: Re: bug#23648: [PATCH] `defun-declarations-alist' can be
 unintentionally modified
Date: Mon, 18 Jul 2016 23:28:55 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Sorry, I guess I'm too stupid to understand this advanced stuff.  Or
> maybe it's too late.

I think the example uses macroexpand only to demonstrate what (obviously
ill) code you will get when you compile the mentioned form after
performing the completion as mentioned.

Michael.

Message #32 received at 23648 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 23648 <at> debbugs.gnu.org, pogonyshev <at> gmail.com, npostavs <at> users.sourceforge.net
Subject: Re: bug#23648: [PATCH] `defun-declarations-alist' can be
 unintentionally modified
Date: Tue, 19 Jul 2016 05:40:53 +0300

> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: Noam Postavsky <npostavs <at> users.sourceforge.net>,  23648 <at> debbugs.gnu.org,  pogonyshev <at> gmail.com
> Date: Mon, 18 Jul 2016 23:28:55 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Sorry, I guess I'm too stupid to understand this advanced stuff.  Or
> > maybe it's too late.
> 
> I think the example uses macroexpand only to demonstrate what (obviously
> ill) code you will get when you compile the mentioned form after
> performing the completion as mentioned.

Thanks, but I'm still none the wiser about the questions I asked.

Message #35 received at 23648 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 23648 <at> debbugs.gnu.org,
 pogonyshev <at> gmail.com
Subject: Re: bug#23648: [PATCH] `defun-declarations-alist' can be
 unintentionally modified
Date: Wed, 20 Jul 2016 21:09:42 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Michael Heerdegen <michael_heerdegen <at> web.de>
>> Cc: Noam Postavsky <npostavs <at> users.sourceforge.net>,  23648 <at> debbugs.gnu.org,  pogonyshev <at> gmail.com
>> Date: Mon, 18 Jul 2016 23:28:55 +0200
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > Sorry, I guess I'm too stupid to understand this advanced stuff.  Or
>> > maybe it's too late.
>> 
>> I think the example uses macroexpand only to demonstrate what (obviously
>> ill) code you will get when you compile the mentioned form after
>> performing the completion as mentioned.
>
> Thanks, but I'm still none the wiser about the questions I asked.

Hmm, maybe it will be clearer like this:

Evaluate:

(macroexpand '(defun foo ()
                (declare (indent 1))
                nil)) ;=> (prog1 (defalias (quote foo) (function (lambda nil nil))) (function-put (quote foo) (quote lisp-indent-function) (quote 1)))

This gives the correct result (the (function-put...) part comes from the
(declare (indent 1))).

Now perform a completion on a declare clause, e.g., put cursor after
"ind" and hit C-M-i: (declare (ind)) completes to (declare (indent)).

Now evaluate the same expression as before:

(macroexpand '(defun foo ()
                (declare (indent 1))
                nil)) ;=> (prog1 (defalias (quote foo) (function (lambda nil nil))) "Warning: Unknown defun property ‘indent’ in foo")

This give the wrong result, the (declare (indent 1)) is giving the
"Warning:...".  Emacs has unlearned the indent declaration.  In fact it
unlearned all the declarations for defun except for gv-setter, you can
see this by looking at defun-declarations-alist's value.

Message #38 received at 23648 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: npostavs <at> users.sourceforge.net
Cc: michael_heerdegen <at> web.de, 23648 <at> debbugs.gnu.org, pogonyshev <at> gmail.com
Subject: Re: bug#23648: [PATCH] `defun-declarations-alist' can be
 unintentionally modified
Date: Thu, 21 Jul 2016 17:22:59 +0300

> From: npostavs <at> users.sourceforge.net
> Cc: Michael Heerdegen <michael_heerdegen <at> web.de>,  23648 <at> debbugs.gnu.org,  pogonyshev <at> gmail.com
> Date: Wed, 20 Jul 2016 21:09:42 -0400
> 
> > Thanks, but I'm still none the wiser about the questions I asked.
> 
> Hmm, maybe it will be clearer like this:
> 
> Evaluate:
> 
> (macroexpand '(defun foo ()
>                 (declare (indent 1))
>                 nil)) ;=> (prog1 (defalias (quote foo) (function (lambda nil 
> nil))) (function-put (quote foo) (quote lisp-indent-function) (quote 1)))
> 
> This gives the correct result (the (function-put...) part comes from the
> (declare (indent 1))).
> 
> Now perform a completion on a declare clause, e.g., put cursor after
> "ind" and hit C-M-i: (declare (ind)) completes to (declare (indent)).
> 
> Now evaluate the same expression as before:
> 
> (macroexpand '(defun foo ()
>                 (declare (indent 1))
>                 nil)) ;=> (prog1 (defalias (quote foo) (function (lambda nil 
> nil))) "Warning: Unknown defun property ‘indent’ in foo")
> 
> This give the wrong result, the (declare (indent 1)) is giving the
> "Warning:...".  Emacs has unlearned the indent declaration.  In fact it
> unlearned all the declarations for defun except for gv-setter, you can
> see this by looking at defun-declarations-alist's value.

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.

Thanks.

Message #41 received at 23648 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 23648 <at> debbugs.gnu.org,
 Paul Pogonyshev <pogonyshev <at> gmail.com>
Subject: Re: bug#23648: [PATCH] `defun-declarations-alist' can be
 unintentionally modified
Date: Thu, 21 Jul 2016 17:27:49 -0400

On Thu, Jul 21, 2016 at 10:22 AM, Eli Zaretskii <eliz <at> 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.

Message #44 received at 23648 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: michael_heerdegen <at> web.de, 23648 <at> debbugs.gnu.org, pogonyshev <at> gmail.com
Subject: Re: bug#23648: [PATCH] `defun-declarations-alist' can be
 unintentionally modified
Date: Sat, 23 Jul 2016 11:54:47 +0300

> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
> Date: Thu, 21 Jul 2016 17:27:49 -0400
> Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 23648 <at> debbugs.gnu.org, 
> 	Paul Pogonyshev <pogonyshev <at> gmail.com>
> 
> > 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.

OK, let's push to emacs-25.  Thanks.

Message #47 received at 23648 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, 23648 <at> debbugs.gnu.org, pogonyshev <at> gmail.com
Subject: Re: bug#23648: [PATCH] `defun-declarations-alist' can be
 unintentionally modified
Date: Sat, 23 Jul 2016 10:18:14 -0400

tags 23648 fixed
close 23648 25.1
quit

Eli Zaretskii <eliz <at> gnu.org> writes:

> OK, let's push to emacs-25.  Thanks.

Push as bc4c07fc.

Message #54 received at 23648 <at> debbugs.gnu.org (full text, mbox):

From: Paul Pogonyshev <pogonyshev <at> gmail.com>
To: npostavs <at> users.sourceforge.net
Cc: michael_heerdegen <at> web.de, Eli Zaretskii <eliz <at> gnu.org>,
 23648 <at> debbugs.gnu.org
Subject: Re: bug#23648: [PATCH] `defun-declarations-alist' can be
 unintentionally modified
Date: Sun, 24 Jul 2016 19:07:59 +0200

Shouldn't it be also merged to master?

Paul

On 23 July 2016 at 16:18,  <npostavs <at> users.sourceforge.net> wrote:
> tags 23648 fixed
> close 23648 25.1
> quit
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> OK, let's push to emacs-25.  Thanks.
>
> Push as bc4c07fc.

Message #57 received at 23648 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Pogonyshev <pogonyshev <at> gmail.com>
Cc: michael_heerdegen <at> web.de, 23648 <at> debbugs.gnu.org,
 npostavs <at> users.sourceforge.net
Subject: Re: bug#23648: [PATCH] `defun-declarations-alist' can be
 unintentionally modified
Date: Sun, 24 Jul 2016 20:31:07 +0300

> From: Paul Pogonyshev <pogonyshev <at> gmail.com>
> Date: Sun, 24 Jul 2016 19:07:59 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 23648 <at> debbugs.gnu.org, michael_heerdegen <at> web.de
> 
> Shouldn't it be also merged to master?

It will be, when the next merge takes place.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.