bug#19552: 25.0.50; void-function class-slot-initarg with new EIEIO changes

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>> The other is the "gh" Github-access package from Melpa: that gives "too
>>> many arguments to defclass".
>> Can you show a backtrace for that error?
> I don't know how to get a proper backtrace for compilation errors...

   (setq debug-on-error t)
   (setq byte-compile-debug t)

And then `M-x byte-compile'.

> Following any of the linked errors leads to the require statements at
> the top of the file in question, and round and round you go.

That's because the error happens while loading the required file.

> I can't actually get to a real error related to defclass. There's
> something odd about the require pattern of this package: gh-auth.el
> ends this way:

> (provide 'gh-auth)
> ;; to avoid circular dependencies...
> (require 'gh-oauth)
> ;;; gh-auth.el ends here

> I don't really understand why. It might be worth getting Yann Hodique to
> comment.

That's usually done because `gh-auth' needs to use functions from
`gh-oauth' and vice-versa, so the author moved the require after the
provide, so that when `gh-oauth' is required from `gh-auth', the
(require 'gh-auth) found in gh-oauth is just skipped (since we just
did (provide 'gh-auth)) rather than causing a recursive load of gh-auth
which would re-require gh-oauth, ...

It's usually not the best solution to recursive dependencies, but
sometimes it's a handy quick-fix, and in this case I don't think it's
the cause of the "Too many arguments to `defclass'" error.


        Stefan