[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#25556: 26.0.50.1; Requiring uncompiled eieio issues obsoletion warni
From: |
David Engster |
Subject: |
bug#25556: 26.0.50.1; Requiring uncompiled eieio issues obsoletion warnings |
Date: |
Sat, 28 Jan 2017 22:15:20 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
'npostavs' writes:
> David Engster <deng@randomsample.de> writes:
>
>> Eli Zaretskii writes:
>>>> From: David Engster <deng@randomsample.de>
>>>> Date: Fri, 27 Jan 2017 21:38:58 +0100
>>>>
>>>
>>>> I'm currently trying to fix compiler warnings during the CEDET compile
>>>> in Emacs master, but there's one annoying problem I'm unsure how to
>>>> fix. Whenever a file does (require 'eieio), and EIEIO is not yet
>>>> byte-compiled, those two warnings are issued:
>>>>
>>>> ../../emacs-lisp/eieio.el: ‘eieio-object-name-string’ is an obsolete
>>>> generic function (as of 25.1); use ‘eieio-named’ instead.
>>>> ../../emacs-lisp/eieio.el: ‘destructor’ is an obsolete generic
>>>> function (as of 26.1).
>>>>
>>>> Since EIEIO is compiled pretty late, one is flooded with these warnings
>>>> when compiling Emacs master. The warnings seems to come from the
>>>> cl-defgeneric for `eieio-object-name-string' and `destructor'. How can
>>>> this be dealt with?
>>>
>>> Is it possibel to arrange that these files be compiled sooner? We
>>> already have some targets for similar purposes in lisp/Makefile.
>>
>> I'm sure that's possible, but why does the file that declares those
>> constructs obsolete *itself* throw these warnings? I was hoping that
>> this could be fixed instead.
>
> I'm not sure about `eieio-object-name-string', but the message about
> `destructor' is because cl-defgeneric makes the declaration handling
> code run before the function defining code, so the symbol is declared
> obsolete before it's defined and the definition itself triggers the
> obsolete warning. The patch below moves it around and stops the
> `destructor' warning:
Thanks for looking into to it, your patch works fine for me. Can this be
applied?
As for eieio-object-name-string, my guess is that this is caused by
declaring it via cl-defgeneric as well as cl-defmethod (the latter even
twice: in eieio.el and eieio-base.el).
-David