all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Noisy byte compilation on master
Date: Mon, 02 Feb 2015 11:31:39 -0500	[thread overview]
Message-ID: <jwvsieogu3w.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <83egq9ipkn.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 01 Feb 2015 18:06:32 +0200")

>   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	other threads:[~2015-02-02 16:31 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-01 16:06 Noisy byte compilation on master Eli Zaretskii
2015-02-02 16:31 ` Stefan Monnier [this message]
2015-02-02 16:35   ` Eli Zaretskii
2015-02-02 18:01   ` Stephen Leake
2015-02-02 23:23     ` Stefan Monnier
2015-02-03  7:03       ` David Engster
2015-02-04 15:45         ` Stefan Monnier
2015-02-15 15:58           ` David Engster
2015-02-16  2:56             ` Stefan Monnier
2015-02-16 21:11               ` David Engster
2015-02-16 23:14                 ` Stefan Monnier
2015-02-17  6:31                   ` David Engster
2015-02-17 23:06                     ` Stefan Monnier
2015-02-18 17:53                       ` David Engster
2015-02-18 19:35                         ` Stefan Monnier
2015-02-18 19:51                           ` David Engster
2015-02-18 22:44                             ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvsieogu3w.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.