bug#25556: 26.0.50.1; Requiring uncompiled eieio issues obsoletion warnings

[David Engster <deng@randomsample.de>]

'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