Re: autoload cl-defstruct constructor?

[Stephen Leake]

Stefan Monnier <address@hidden> writes:

>> I tried adding an autoload cookie to the cl-defstruct. That almost
>> works, but update-directory-autoloads doesn't respect the order implied
>> by :include, so wisi-compiler is declared in autoloads.el after it is
>> needed.
>
> Could you give details about this ordering problem?

Hmm. Attempting to reproduce this, I ran into a different but related
problem.

If I add an autoload cookie to a cl-defstruct, running
update-directory-autoloads on the above gives:

---

;;; Generated autoloads from gnat-core.el

(cl-defstruct gnat-compiler "\
Used with wisi-compiler-* generic functions." gpr-file run-buffer-name 
project-path target runtime gnat-stub-opts gnat-stub-cargs)

---

There is no "autoload" call, as there would be with a normal function.
So even though 'make-gnat-compiler' is defined, calling it does not load
gnat-core.el, so no other functions are defined.

So more autoloads are required. Not really a problem, but unexpected.

> It sounds like a bug (tho fixing it will probably not help you in the
> short-run if you need your solution to work in Emacs-26).

The files are included in autoloads.el in file name alphabetical order
(although there do seem to be exceptions?). So with my real code, I get:

--- 

;;; Generated autoloads from ada-core.el

...

(cl-defstruct (ada-prj (:include wisi-prj) (:copier nil) (:constructor nil) 
(:constructor make-ada-prj (&key name compile-env (compiler-label ada-compiler) 
(xref-label ada-xref-tool) source-path plist file-pred &aux (compiler 
(ada-prj-make-compiler compiler-label)) (xref (ada-prj-make-xref 
xref-label))))) plist)

...

;;; Generated autoloads from wisi-prj.el

(cl-defstruct wisi-prj name compile-env file-env compiler xref 
(case-exception-files nil) (case-full-exceptions 'nil) (case-partial-exceptions 
'nil) source-path file-pred)


---

At the point where 'ada-prj' is declared, 'wisi-prj' is unknown.

I can create a simple reproducer for a bug report, if you think that's
warrented.

For now, I'll try the renamed constructor approach.

-- 
-- Stephe