emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Noisy byte compilation on master


From: Stefan Monnier
Subject: Re: Noisy byte compilation on master
Date: Mon, 02 Feb 2015 11:31:39 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

>   In semantic-decoration-all-include-summary:
>   cedet/semantic/decorate/include.el:803:58:Warning: 
> `eieio-object-name-string'
>       is an obsolete function (as of 25.1); use `eieio-named' instead.
>   cedet/semantic/decorate/include.el:809:46:Warning: 
> `eieio-object-name-string'
>       is an obsolete function (as of 25.1); use `eieio-named' instead.
>   `defmethod' is an obsolete macro (as of 25.1); use `cl-defmethod' instead.
>   `defgeneric' is an obsolete macro (as of 25.1); use `cl-defgeneric' instead.
>   `defmethod' is an obsolete macro (as of 25.1); use `cl-defmethod' instead.
>   `defgeneric' is an obsolete macro (as of 25.1); use `cl-defgeneric' instead.
>   `defmethod' is an obsolete macro (as of 25.1); use `cl-defmethod' instead.
>   `defgeneric' is an obsolete macro (as of 25.1); use `cl-defgeneric' instead.

Not sure what to do about these: CEDET needs to work with older
Emascsen, so we can't change the code to use the cl-defmethod thingies yet.
But in the Emacs master code, `defmethod' is a compatibility layer which
introduces notable inefficiencies, so we do want to mark those as obsolete.

Maybe we should keep those as "not quite obsolete yet" and only add the
obsolescence warnings when we get to Emacs-26?  Or else, (define and)
add extra annotations in those CEDET files to silence those warnings?

>   Warning: Using brain-dead macro `mm-with-unibyte-current-buffer'!
>   utf7.el: `mm-with-unibyte-current-buffer' is an obsolete macro (as of 25.1).

This one is also problematic: I've been trying to reduce the use of this
macro for several years now, but I don't know the Gnus code enough to do
much further progress.  Yet, this macro is sufficiently ill-defined that
I think most of its uses probably suffer from latent bugs.  So spewing
warnings during compilation sounds like the right thing to do (tho
I see they're duplicated: one from the macro itself and one from the
obsolescence warning, so we can drop the "Warning:" message).


        Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]