bug#50898: 28.0.50; with-suppressed-warnings doesn't always work

bug#50898: 28.0.50; with-suppressed-warnings doesn't always work

[Lars Ingebrigtsen]

For some time now, the only compilation warning in Emacs has been:

In toplevel form:
cedet/semantic/bovine/el.el:931:1: Warning: ‘define-child-mode’ is an obsolete
    macro (as of 27.1); use ‘define-derived-mode’ instead.

(It appears in two places.)  But I've forgotten to look into it.

This warning is supposed to be suppressed:

(with-suppressed-warnings ((obsolete define-child-mode))
  ;; FIXME: We should handle this some other way!
  (define-child-mode lisp-mode emacs-lisp-mode
    "Make `lisp-mode' inherit mode local behavior from `emacs-lisp-mode'."))

And this suppression did work at some point, I think?  But it's not
working any more.

I haven't tried to debug it (or bisect it) yet, but perhaps it's obvious
to somebody what change may have triggered this?  My uninformed guess
might be something to do with...  macros and when they are expanded?

I've added Stefan M to the CCs.



In GNU Emacs 28.0.50 (build 23, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
 of 2021-09-26 built on elva
Repository revision: 43ae8c828d853382bbc2a27b9e14b9fff6ba18b6
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#50898: 28.0.50; with-suppressed-warnings doesn't always work

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> (with-suppressed-warnings ((obsolete define-child-mode))
>   ;; FIXME: We should handle this some other way!
>   (define-child-mode lisp-mode emacs-lisp-mode
>     "Make `lisp-mode' inherit mode local behavior from `emacs-lisp-mode'."))
>
> And this suppression did work at some point, I think?  But it's not
> working any more.

Indeed, i experienced the same thing in another case in my own code.
And I am sure that it worked as expected in the past.

Michael.

bug#50898: 28.0.50; with-suppressed-warnings doesn't always work

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> (with-suppressed-warnings ((obsolete define-child-mode))
>>   ;; FIXME: We should handle this some other way!
>>   (define-child-mode lisp-mode emacs-lisp-mode
>>     "Make `lisp-mode' inherit mode local behavior from `emacs-lisp-mode'."))
>>
>> And this suppression did work at some point, I think?  But it's not
>> working any more.
>
> Indeed, i experienced the same thing in another case in my own code.
> And I am sure that it worked as expected in the past.

This should now work again on the trunk.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#50898: 28.0.50; with-suppressed-warnings doesn't always work

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

> This should now work again on the trunk.

Hmm...

    @@ -216,10 +216,11 @@ macroexp-macroexpand
             (let* ((fun (car form))
                    (obsolete (get fun 'byte-obsolete-info)))
               (macroexp-warn-and-return
    -           (macroexp--obsolete-warning
    -            fun obsolete
    -            (if (symbolp (symbol-function fun))
    -                "alias" "macro"))
    +           (and (byte-compile-warning-enabled-p 'obsolete fun)
    +                (macroexp--obsolete-warning
    +                 fun obsolete
    +                 (if (symbolp (symbol-function fun))
    +                     "alias" "macro")))
                new-form 'obsolete))
           new-form)))

I suspect this can fail if `bytecomp.el` is not yet loaded.

I think "the right way" to do that is to improve
`macroexp-warn-and-return` so that instead of only receiving `obsolete`
as `category` to decide if the warning is enabled or not, it should
additionally also receive `fun`.


        Stefan

bug#50898: 28.0.50; with-suppressed-warnings doesn't always work

[Lars Ingebrigtsen]

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

> I suspect this can fail if `bytecomp.el` is not yet loaded.

In what cases does that happen?  I tried both an incremental and
a bootstrap build.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#50898: 28.0.50; with-suppressed-warnings doesn't always work

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

Lars Ingebrigtsen [2021-11-30 15:19:55] wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> I suspect this can fail if `bytecomp.el` is not yet loaded.
>
> In what cases does that happen?  I tried both an incremental and
> a bootstrap build.


    emacs -Q
    (with-suppressed-warnings ((obsolete foo)) (define-child-mode sm-foo c-mode "hello"))
    C-j


-- Stefan

bug#50898: 28.0.50; with-suppressed-warnings doesn't always work

[Lars Ingebrigtsen]

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

>> In what cases does that happen?  I tried both an incremental and
>> a bootstrap build.
>
>     emacs -Q
>     (with-suppressed-warnings ((obsolete foo)) (define-child-mode
> sm-foo c-mode "hello"))
>     C-j

Right.  But instead of duplicating the logic, autoloading
byte-compile-warning-enabled-p would fix that problem.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no