bug#73881: 31.0.50; Unexpected warnings about recursive occurrences of obsolete functions

bug#73881: 31.0.50; Unexpected warnings about recursive occurrences of obsolete functions

[Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

bug#73881: 31.0.50; Unexpected warnings about recursive occurrences of obsolete functions

[Eli Zaretskii]

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

bug#73881: 31.0.50; Unexpected warnings about recursive occurrences of obsolete functions

[Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hi,

Eli Zaretskii <eliz@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@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"))
 

bug#73881: 31.0.50; Unexpected warnings about recursive occurrences of obsolete functions

[Eli Zaretskii]

> From: Eshel Yaron <me@eshelyaron.com>
> Cc: 73881@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.

bug#73881: 31.0.50; Unexpected warnings about recursive occurrences of obsolete functions

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

bug#73881: 31.0.50; Unexpected warnings about recursive occurrences of obsolete functions

[Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hi,

Stefan Monnier <monnier@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

bug#73881: 31.0.50; Unexpected warnings about recursive occurrences of obsolete functions

[Stefan Kangas]

Stefan Monnier <monnier@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.

bug#73881: 31.0.50; Unexpected warnings about recursive occurrences of obsolete functions

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

bug#73881: 31.0.50; Unexpected warnings about recursive occurrences of obsolete functions

[Stefan Kangas]

Stefan Monnier <monnier@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.

bug#73881: 31.0.50; Unexpected warnings about recursive occurrences of obsolete functions

[Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Kangas <stefankangas@gmail.com> writes:

> Stefan Monnier <monnier@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

bug#73881: 31.0.50; Unexpected warnings about recursive occurrences of obsolete functions

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> 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

bug#73881: 31.0.50; Unexpected warnings about recursive occurrences of obsolete functions

[Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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