all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#73881: 31.0.50; Unexpected warnings about recursive occurrences of obsolete functions
@ 2024-10-19 13:21 Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-10-19 14:34 ` Eli Zaretskii
  0 siblings, 1 reply; 12+ messages in thread
From: Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-10-19 13:21 UTC (permalink / raw)
  To: 73881


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





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#73881: 31.0.50; Unexpected warnings about recursive occurrences of obsolete functions
  2024-10-19 13:21 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
@ 2024-10-19 14:34 ` Eli Zaretskii
  2024-10-19 18:11   ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2024-10-19 14:34 UTC (permalink / raw)
  To: Eshel Yaron; +Cc: 73881

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





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#73881: 31.0.50; Unexpected warnings about recursive occurrences of obsolete functions
  2024-10-19 14:34 ` Eli Zaretskii
@ 2024-10-19 18:11   ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-10-19 18:15     ` Eli Zaretskii
  0 siblings, 1 reply; 12+ messages in thread
From: Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-10-19 18:11 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 73881

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





^ permalink raw reply related	[flat|nested] 12+ messages in thread

* bug#73881: 31.0.50; Unexpected warnings about recursive occurrences of obsolete functions
  2024-10-19 18:11   ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-10-19 18:15     ` Eli Zaretskii
  2024-10-20  2:24       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2024-10-19 18:15 UTC (permalink / raw)
  To: Eshel Yaron, Stefan Monnier, Stefan Kangas, Andrea Corallo; +Cc: 73881

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





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#73881: 31.0.50; Unexpected warnings about recursive occurrences of obsolete functions
  2024-10-19 18:15     ` Eli Zaretskii
@ 2024-10-20  2:24       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-10-20  7:08         ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-10-20 11:51         ` Stefan Kangas
  0 siblings, 2 replies; 12+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-10-20  2:24 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 73881, Andrea Corallo, Eshel Yaron, Stefan Kangas

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






^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#73881: 31.0.50; Unexpected warnings about recursive occurrences of obsolete functions
  2024-10-20  2:24       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-10-20  7:08         ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-10-20 11:51         ` Stefan Kangas
  1 sibling, 0 replies; 12+ messages in thread
From: Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-10-20  7:08 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Eli Zaretskii, Andrea Corallo, 73881, Stefan Kangas

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





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#73881: 31.0.50; Unexpected warnings about recursive occurrences of obsolete functions
  2024-10-20  2:24       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-10-20  7:08         ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-10-20 11:51         ` Stefan Kangas
  2024-10-27 19:18           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 1 reply; 12+ messages in thread
From: Stefan Kangas @ 2024-10-20 11:51 UTC (permalink / raw)
  To: Stefan Monnier, Eli Zaretskii; +Cc: 73881, Andrea Corallo, Eshel Yaron

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.





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#73881: 31.0.50; Unexpected warnings about recursive occurrences of obsolete functions
  2024-10-20 11:51         ` Stefan Kangas
@ 2024-10-27 19:18           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-10-28 22:32             ` Stefan Kangas
  0 siblings, 1 reply; 12+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-10-27 19:18 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: 73881, Eli Zaretskii, Andrea Corallo, Eshel Yaron

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






^ permalink raw reply related	[flat|nested] 12+ messages in thread

* bug#73881: 31.0.50; Unexpected warnings about recursive occurrences of obsolete functions
  2024-10-27 19:18           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-10-28 22:32             ` Stefan Kangas
  2024-10-29  7:21               ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 12+ messages in thread
From: Stefan Kangas @ 2024-10-28 22:32 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 73881, Eli Zaretskii, Andrea Corallo, Eshel Yaron

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.





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#73881: 31.0.50; Unexpected warnings about recursive occurrences of obsolete functions
  2024-10-28 22:32             ` Stefan Kangas
@ 2024-10-29  7:21               ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-10-30  2:24                 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 12+ messages in thread
From: Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-10-29  7:21 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Eli Zaretskii, Andrea Corallo, 73881, Stefan Monnier

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





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#73881: 31.0.50; Unexpected warnings about recursive occurrences of obsolete functions
  2024-10-29  7:21               ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-10-30  2:24                 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-10-30  7:17                   ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 12+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-10-30  2:24 UTC (permalink / raw)
  To: Eshel Yaron; +Cc: Eli Zaretskii, Andrea Corallo, 73881, Stefan Kangas

> 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






^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#73881: 31.0.50; Unexpected warnings about recursive occurrences of obsolete functions
  2024-10-30  2:24                 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-10-30  7:17                   ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 0 replies; 12+ messages in thread
From: Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-10-30  7:17 UTC (permalink / raw)
  To: 73881; +Cc: eliz, acorallo, monnier, stefankangas

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





^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2024-10-30  7:17 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-10-19 13:21 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
2024-10-19 14:34 ` Eli Zaretskii
2024-10-19 18:11   ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-19 18:15     ` Eli Zaretskii
2024-10-20  2:24       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-20  7:08         ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-20 11:51         ` Stefan Kangas
2024-10-27 19:18           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-28 22:32             ` Stefan Kangas
2024-10-29  7:21               ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-30  2:24                 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-30  7:17                   ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.