GNU bug report logs - #73881
31.0.50; Unexpected warnings about recursive occurrences of obsolete functions

Previous Next

To reply to this bug, email your comments to 73881 AT debbugs.gnu.org.

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

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

From: Eshel Yaron <me <at> eshelyaron.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; Unexpected warnings about recursive occurrences of
 obsolete functions
Date: Sat, 19 Oct 2024 15:21:22 +0200

1. emacs -Q
2. (require 'allout) or otherwise load allout.el
3. Byte-compile allout.el with M-x byte-compile-file
4. See warnings:

--8<---------------cut here---------------start------------->8---
In allout-old-expose-topic:
allout.el:5092:29: Warning: ‘allout-old-expose-topic’ is an obsolete function
    (as of 28.1); use ‘allout-expose-topic’ instead.
allout.el:5097:44: Warning: ‘allout-old-expose-topic’ is an obsolete function
    (as of 28.1); use ‘allout-expose-topic’ instead.
allout.el:5106:8: Warning: ‘allout-old-expose-topic’ is an obsolete function
    (as of 28.1); use ‘allout-expose-topic’ instead.
--8<---------------cut here---------------end--------------->8---

These warnings are unhelpful since these are recursive calls within the
definition of the obsolete function itself.  They need not be replaced
with another function as the warnings suggest.  Ideally, recursive calls
to obsolete functions should not produce such warnings.


Best,

Eshel

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: 73881 <at> debbugs.gnu.org
Subject: Re: bug#73881: 31.0.50;
 Unexpected warnings about recursive occurrences of obsolete functions
Date: Sat, 19 Oct 2024 17:34:31 +0300

> Date: Sat, 19 Oct 2024 15:21:22 +0200
> From:  Eshel Yaron via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> 
> 1. emacs -Q
> 2. (require 'allout) or otherwise load allout.el
> 3. Byte-compile allout.el with M-x byte-compile-file
> 4. See warnings:
> 
> --8<---------------cut here---------------start------------->8---
> In allout-old-expose-topic:
> allout.el:5092:29: Warning: ‘allout-old-expose-topic’ is an obsolete function
>     (as of 28.1); use ‘allout-expose-topic’ instead.
> allout.el:5097:44: Warning: ‘allout-old-expose-topic’ is an obsolete function
>     (as of 28.1); use ‘allout-expose-topic’ instead.
> allout.el:5106:8: Warning: ‘allout-old-expose-topic’ is an obsolete function
>     (as of 28.1); use ‘allout-expose-topic’ instead.
> --8<---------------cut here---------------end--------------->8---
> 
> These warnings are unhelpful since these are recursive calls within the
> definition of the obsolete function itself.  They need not be replaced
> with another function as the warnings suggest.  Ideally, recursive calls
> to obsolete functions should not produce such warnings.

From where I stand, this could be closed as wontfix, unless someone
sees an easy fix.  I don't see any harm from emitting these warnings
in this scenario.  The warnings are correct.

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

From: Eshel Yaron <me <at> eshelyaron.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 73881 <at> debbugs.gnu.org
Subject: Re: bug#73881: 31.0.50; Unexpected warnings about recursive
 occurrences of obsolete functions
Date: Sat, 19 Oct 2024 20:11:08 +0200

Hi,

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

>> Date: Sat, 19 Oct 2024 15:21:22 +0200
>> From:  Eshel Yaron via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> 
>> 
>> 1. emacs -Q
>> 2. (require 'allout) or otherwise load allout.el
>> 3. Byte-compile allout.el with M-x byte-compile-file
>> 4. See warnings:
>> 
>> --8<---------------cut here---------------start------------->8---
>> In allout-old-expose-topic:
>> allout.el:5092:29: Warning: ‘allout-old-expose-topic’ is an obsolete function
>>     (as of 28.1); use ‘allout-expose-topic’ instead.
>> allout.el:5097:44: Warning: ‘allout-old-expose-topic’ is an obsolete function
>>     (as of 28.1); use ‘allout-expose-topic’ instead.
>> allout.el:5106:8: Warning: ‘allout-old-expose-topic’ is an obsolete function
>>     (as of 28.1); use ‘allout-expose-topic’ instead.
>> --8<---------------cut here---------------end--------------->8---
>> 
>> These warnings are unhelpful since these are recursive calls within the
>> definition of the obsolete function itself.  They need not be replaced
>> with another function as the warnings suggest.  Ideally, recursive calls
>> to obsolete functions should not produce such warnings.
>
> From where I stand, this could be closed as wontfix, unless someone
> sees an easy fix.  I don't see any harm from emitting these warnings
> in this scenario.  The warnings are correct.

All right, FWIW I find them more distracting then helpful: if I'm
declaring a function as obsolete, that means it's going to stay around
for at least a short while, with its recursive calls, which I have no
interest in adapting.  So these warnings do not tell me anything useful.

As for an easy fix, maybe something like this?

diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el
index 29e7882c851..edb8160a250 100644
--- a/lisp/emacs-lisp/bytecomp.el
+++ b/lisp/emacs-lisp/bytecomp.el
@@ -1533,6 +1533,7 @@ byte-compile-arglist-signature-string
 
 (defun byte-compile-function-warn (f nargs def)
   (when (and (get f 'byte-obsolete-info)
+             (not (eq f byte-compile-current-form)) ; Recursive call.
              (not (memq f byte-compile-not-obsolete-funcs)))
     (byte-compile-warn-obsolete f "function"))
 

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eshel Yaron <me <at> eshelyaron.com>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Stefan Kangas <stefankangas <at> gmail.com>, Andrea Corallo <acorallo <at> gnu.org>
Cc: 73881 <at> debbugs.gnu.org
Subject: Re: bug#73881: 31.0.50; Unexpected warnings about recursive
 occurrences of obsolete functions
Date: Sat, 19 Oct 2024 21:15:42 +0300

> From: Eshel Yaron <me <at> eshelyaron.com>
> Cc: 73881 <at> debbugs.gnu.org
> Date: Sat, 19 Oct 2024 20:11:08 +0200
> 
> >> In allout-old-expose-topic:
> >> allout.el:5092:29: Warning: ‘allout-old-expose-topic’ is an obsolete function
> >>     (as of 28.1); use ‘allout-expose-topic’ instead.
> >> allout.el:5097:44: Warning: ‘allout-old-expose-topic’ is an obsolete function
> >>     (as of 28.1); use ‘allout-expose-topic’ instead.
> >> allout.el:5106:8: Warning: ‘allout-old-expose-topic’ is an obsolete function
> >>     (as of 28.1); use ‘allout-expose-topic’ instead.
> >> --8<---------------cut here---------------end--------------->8---
> >> 
> >> These warnings are unhelpful since these are recursive calls within the
> >> definition of the obsolete function itself.  They need not be replaced
> >> with another function as the warnings suggest.  Ideally, recursive calls
> >> to obsolete functions should not produce such warnings.
> >
> > From where I stand, this could be closed as wontfix, unless someone
> > sees an easy fix.  I don't see any harm from emitting these warnings
> > in this scenario.  The warnings are correct.
> 
> All right, FWIW I find them more distracting then helpful: if I'm
> declaring a function as obsolete, that means it's going to stay around
> for at least a short while, with its recursive calls, which I have no
> interest in adapting.  So these warnings do not tell me anything useful.
> 
> As for an easy fix, maybe something like this?
> 
> diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el
> index 29e7882c851..edb8160a250 100644
> --- a/lisp/emacs-lisp/bytecomp.el
> +++ b/lisp/emacs-lisp/bytecomp.el
> @@ -1533,6 +1533,7 @@ byte-compile-arglist-signature-string
>  
>  (defun byte-compile-function-warn (f nargs def)
>    (when (and (get f 'byte-obsolete-info)
> +             (not (eq f byte-compile-current-form)) ; Recursive call.
>               (not (memq f byte-compile-not-obsolete-funcs)))
>      (byte-compile-warn-obsolete f "function"))

Thanks, let's see what others think about this.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 73881 <at> debbugs.gnu.org, Andrea Corallo <acorallo <at> gnu.org>,
 Eshel Yaron <me <at> eshelyaron.com>, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#73881: 31.0.50; Unexpected warnings about recursive
 occurrences of obsolete functions
Date: Sat, 19 Oct 2024 22:24:57 -0400

>> As for an easy fix, maybe something like this?
>> 
>> diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el
>> index 29e7882c851..edb8160a250 100644
>> --- a/lisp/emacs-lisp/bytecomp.el
>> +++ b/lisp/emacs-lisp/bytecomp.el
>> @@ -1533,6 +1533,7 @@ byte-compile-arglist-signature-string
>>  
>>  (defun byte-compile-function-warn (f nargs def)
>>    (when (and (get f 'byte-obsolete-info)
>> +             (not (eq f byte-compile-current-form)) ; Recursive call.
>>               (not (memq f byte-compile-not-obsolete-funcs)))
>>      (byte-compile-warn-obsolete f "function"))
>
> Thanks, let's see what others think about this.

Hmm... I distinctly remember writing code to try and silence
obsolescence warnings in the code coming from the same file as the
`make-obsolete` call.

If I installed that code into Emacs, clearly it's not doing its job.

..Hmm.. I think I see the problem: the code I wrote was for variables
rather than for functions:

    ;; If foo.el declares `toto' as obsolete, it is likely that foo.el will
    ;; actually use `toto' in order for this obsolete variable to still work
    ;; correctly, so paradoxically, while byte-compiling foo.el, the presence
    ;; of a make-obsolete-variable call for `toto' is an indication that `toto'
    ;; should not trigger obsolete-warnings in foo.el.
    (byte-defop-compiler-1 make-obsolete-variable)
    (defun byte-compile-make-obsolete-variable (form)
      (when (eq 'quote (car-safe (nth 1 form)))
        (push (nth 1 (nth 1 form)) byte-compile-global-not-obsolete-vars))
      (byte-compile-normal-call form))

So maybe we should just do the same for `make-obsolete`?


        Stefan

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

From: Eshel Yaron <me <at> eshelyaron.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Andrea Corallo <acorallo <at> gnu.org>,
 73881 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#73881: 31.0.50; Unexpected warnings about recursive
 occurrences of obsolete functions
Date: Sun, 20 Oct 2024 09:08:05 +0200

Hi,

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> Hmm... I distinctly remember writing code to try and silence
> obsolescence warnings in the code coming from the same file as the
> `make-obsolete` call.

Ah good, sounds like a reasonable heuristic.

> If I installed that code into Emacs, clearly it's not doing its job.
>
> ..Hmm.. I think I see the problem: the code I wrote was for variables
> rather than for functions:
>
>     ;; If foo.el declares `toto' as obsolete, it is likely that foo.el will
>     ;; actually use `toto' in order for this obsolete variable to still work
>     ;; correctly, so paradoxically, while byte-compiling foo.el, the presence
>     ;; of a make-obsolete-variable call for `toto' is an indication that `toto'
>     ;; should not trigger obsolete-warnings in foo.el.
>     (byte-defop-compiler-1 make-obsolete-variable)
>     (defun byte-compile-make-obsolete-variable (form)
>       (when (eq 'quote (car-safe (nth 1 form)))
>         (push (nth 1 (nth 1 form)) byte-compile-global-not-obsolete-vars))
>       (byte-compile-normal-call form))
>
> So maybe we should just do the same for `make-obsolete`?

SGTM.


Thanks,

Eshel

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 73881 <at> debbugs.gnu.org, Andrea Corallo <acorallo <at> gnu.org>,
 Eshel Yaron <me <at> eshelyaron.com>
Subject: Re: bug#73881: 31.0.50; Unexpected warnings about recursive
 occurrences of obsolete functions
Date: Sun, 20 Oct 2024 04:51:53 -0700

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> ..Hmm.. I think I see the problem: the code I wrote was for variables
> rather than for functions:
>
>     ;; If foo.el declares `toto' as obsolete, it is likely that foo.el will
>     ;; actually use `toto' in order for this obsolete variable to still work
>     ;; correctly, so paradoxically, while byte-compiling foo.el, the presence
>     ;; of a make-obsolete-variable call for `toto' is an indication that `toto'
>     ;; should not trigger obsolete-warnings in foo.el.
>     (byte-defop-compiler-1 make-obsolete-variable)
>     (defun byte-compile-make-obsolete-variable (form)
>       (when (eq 'quote (car-safe (nth 1 form)))
>         (push (nth 1 (nth 1 form)) byte-compile-global-not-obsolete-vars))
>       (byte-compile-normal-call form))
>
> So maybe we should just do the same for `make-obsolete`?

I think that makes sense.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 73881 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Andrea Corallo <acorallo <at> gnu.org>, Eshel Yaron <me <at> eshelyaron.com>
Subject: Re: bug#73881: 31.0.50; Unexpected warnings about recursive
 occurrences of obsolete functions
Date: Sun, 27 Oct 2024 15:18:51 -0400

>> ..Hmm.. I think I see the problem: the code I wrote was for variables
>> rather than for functions:
>>
>>     ;; If foo.el declares `toto' as obsolete, it is likely that foo.el will
>>     ;; actually use `toto' in order for this obsolete variable to still work
>>     ;; correctly, so paradoxically, while byte-compiling foo.el, the presence
>>     ;; of a make-obsolete-variable call for `toto' is an indication that `toto'
>>     ;; should not trigger obsolete-warnings in foo.el.
>>     (byte-defop-compiler-1 make-obsolete-variable)
>>     (defun byte-compile-make-obsolete-variable (form)
>>       (when (eq 'quote (car-safe (nth 1 form)))
>>         (push (nth 1 (nth 1 form)) byte-compile-global-not-obsolete-vars))
>>       (byte-compile-normal-call form))
>>
>> So maybe we should just do the same for `make-obsolete`?
>
> I think that makes sense.

I propose the patch below (which also fixes a leak of
`byte-compile-global-not-obsolete-vars` to code compiled from other
files).
But I don't think it fixes the OP's problem because

    (macroexpand '(defun my-foo () (declare (obsolete "blabla" "25")) 42))
=>
    (prog1 (defalias 'my-foo #'(lambda nil ...))
      (make-obsolete 'my-foo '"blabla" "25"))

IOW, the `make-obsolete` comes *after* the function and thus my new code
will only silence warnings for calls to `my-foo` that are present
*after* the function definition.


        Stefan


diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el
index f058fc48cc7..efa1ea6b676 100644
--- a/lisp/emacs-lisp/bytecomp.el
+++ b/lisp/emacs-lisp/bytecomp.el
@@ -433,8 +433,6 @@ byte-compile-interactive-only-functions
 
 (defvar byte-compile-not-obsolete-vars nil
   "List of variables that shouldn't be reported as obsolete.")
-(defvar byte-compile-global-not-obsolete-vars nil
-  "Global list of variables that shouldn't be reported as obsolete.")
 
 (defvar byte-compile-not-obsolete-funcs nil
   "List of functions that shouldn't be reported as obsolete.")
@@ -1909,6 +1907,8 @@ byte-compile-close-variables
          (byte-compile-const-variables nil)
          (byte-compile-free-references nil)
          (byte-compile-free-assignments nil)
+         (byte-compile-not-obsolete-vars nil)
+         (byte-compile-not-obsolete-funcs nil)
          ;;
          ;; Close over these variables so that `byte-compiler-options'
          ;; can change them on a per-file basis.
@@ -2764,6 +2764,8 @@ byte-compile-file-form-with-suppressed-warnings
 ;; Automatically evaluate define-obsolete-function-alias etc at top-level.
 (put 'make-obsolete 'byte-hunk-handler 'byte-compile-file-form-make-obsolete)
 (defun byte-compile-file-form-make-obsolete (form)
+  (when (eq 'quote (car-safe (nth 1 form)))
+    (push (nth 1 (nth 1 form)) byte-compile-not-obsolete-funcs))
   (prog1 (byte-compile-keep-pending form)
     (apply 'make-obsolete
            (mapcar 'eval (cdr form)))))
@@ -3808,7 +3810,6 @@ byte-compile-check-variable
 	((let ((od (get var 'byte-obsolete-variable)))
            (and od
                 (not (memq var byte-compile-not-obsolete-vars))
-                (not (memq var byte-compile-global-not-obsolete-vars))
                 (not (memq var byte-compile-lexical-variables))
                 (pcase (nth 1 od)
                   ('set (not (eq access-type 'reference)))
@@ -5068,7 +5069,7 @@ lambda
 (byte-defop-compiler-1 make-obsolete-variable)
 (defun byte-compile-make-obsolete-variable (form)
   (when (eq 'quote (car-safe (nth 1 form)))
-    (push (nth 1 (nth 1 form)) byte-compile-global-not-obsolete-vars))
+    (push (nth 1 (nth 1 form)) byte-compile-not-obsolete-vars))
   (byte-compile-normal-call form))
 
 (defun byte-compile-defvar (form &optional toplevel)

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 73881 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Andrea Corallo <acorallo <at> gnu.org>, Eshel Yaron <me <at> eshelyaron.com>
Subject: Re: bug#73881: 31.0.50; Unexpected warnings about recursive
 occurrences of obsolete functions
Date: Mon, 28 Oct 2024 15:32:52 -0700

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> I propose the patch below (which also fixes a leak of
> `byte-compile-global-not-obsolete-vars` to code compiled from other
> files).
> But I don't think it fixes the OP's problem because
>
>     (macroexpand '(defun my-foo () (declare (obsolete "blabla" "25")) 42))
> =>
>     (prog1 (defalias 'my-foo #'(lambda nil ...))
>       (make-obsolete 'my-foo '"blabla" "25"))
>
> IOW, the `make-obsolete` comes *after* the function and thus my new code
> will only silence warnings for calls to `my-foo` that are present
> *after* the function definition.

It looks like a step in the right direction to me.

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

From: Eshel Yaron <me <at> eshelyaron.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Andrea Corallo <acorallo <at> gnu.org>,
 73881 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#73881: 31.0.50; Unexpected warnings about recursive
 occurrences of obsolete functions
Date: Tue, 29 Oct 2024 08:21:00 +0100

Stefan Kangas <stefankangas <at> gmail.com> writes:

> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
>> I propose the patch below (which also fixes a leak of
>> `byte-compile-global-not-obsolete-vars` to code compiled from other
>> files).
>> But I don't think it fixes the OP's problem because
>>
>>     (macroexpand '(defun my-foo () (declare (obsolete "blabla" "25")) 42))
>> =>
>>     (prog1 (defalias 'my-foo #'(lambda nil ...))
>>       (make-obsolete 'my-foo '"blabla" "25"))
>>
>> IOW, the `make-obsolete` comes *after* the function and thus my new code
>> will only silence warnings for calls to `my-foo` that are present
>> *after* the function definition.
>
> It looks like a step in the right direction to me.

To me as well.  Would there any harm in emitting the make-obsolete form
above the defalias form to cover also the warnings for recursive calls?


Best,

Eshel

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Andrea Corallo <acorallo <at> gnu.org>,
 73881 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#73881: 31.0.50; Unexpected warnings about recursive
 occurrences of obsolete functions
Date: Tue, 29 Oct 2024 22:24:05 -0400

> To me as well.  Would there any harm in emitting the make-obsolete form
> above the defalias form to cover also the warnings for recursive calls?

I can come up with scenarios where it would, of course, but they're
probably not too important.

OTOH these entries are generated by a generic piece of code which
handles all the `declare` thingies and puts them all after the function
definition, and moving them *all* would seem a lot more risky.


        Stefan

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

From: Eshel Yaron <me <at> eshelyaron.com>
To: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Andrea Corallo <acorallo <at> gnu.org>,
 73881 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#73881: 31.0.50; Unexpected warnings about recursive
 occurrences of obsolete functions
Date: Wed, 30 Oct 2024 08:17:51 +0100

Hi,

Stefan Monnier writes:

>> To me as well.  Would there any harm in emitting the make-obsolete form
>> above the defalias form to cover also the warnings for recursive calls?
>
> I can come up with scenarios where it would, of course, but they're
> probably not too important.
>
> OTOH these entries are generated by a generic piece of code which
> handles all the `declare` thingies and puts them all after the function
> definition, and moving them *all* would seem a lot more risky.

Right, it's slightly complicated...  So how about using my one-line
patch from upthread, which takes care of recursive calls specifically,
along with your patch?


Eshel

Previous Next

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