fasl writing fails with "attempt to dump invalid structure"

[Attila Lendvai]

when compiling the attached file i get the attached backtrace:

(compile-file "/tmp/fasl-struct-bug.lisp")

attempt to dump invalid structure:
  #<COMMON-LISP-USER::CLAZZ {1006946AC1}>
How did this happen?

there's some mechanism in the dumper to register "valid" (?) structs in (fasl-output-valid-structures file) when *dump-only-valid-structures* is true. in the example, the macro transforms the literal clos instance created by a reader macro into something else (nil in the minimalistic example). probably due to this the struct is not registered in an earlier phase and the fasl writer errors.

please note that it works as expected in the function body, but no in the default expression of a keyword arg.

[Nikodemus Siivola (nikodemus)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 status confirmed
 importance medium
 tags compiler

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAklN7hIACgkQbSpkIAKPfsVXTwCfSuMCmgo2yjxi1Nd0WQz4eUQf
XMcAnRYQVAzE0Bsb/IwvCH1XnRyZC4I+
=LpgP
-----END PGP SIGNATURE-----

[Alastair Bridgewater (alastair-bridgewater)]

This occurs because make-load-form processing (compiler/main.lisp:emit-make-load-form, compiler/ir1tran.lisp:maybe-emit-make-load-forms, possibly compiler/ir1util.lisp:find-constant) is not run on the arglists for function entries and probably should.

[Alastair Bridgewater (alastair-bridgewater)]

It appears that the only place that ir2-component-entries for a component is populated is compiler/entry:entry-analyze. This function calls compiler/entry:compute-entry-info in order to populate the entry-info structure. The following patch appears to fix the problem. However, src/compiler/entry:entry-analyze checks for an existing entry-info structure on each candidate lambda and I am unsure if this is dead code or if there are any consequences to processing a form multiple times with compiler/ir1tran:maybe-make-load-forms.

I should like to commit this at some point in the next week unless someone can tell me why it would be a bad idea to do so.

diff --git a/src/compiler/entry.lisp b/src/compiler/entry.lisp
index ae95297..83d5a00 100644
--- a/src/compiler/entry.lisp
+++ b/src/compiler/entry.lisp
@@ -51,7 +51,12 @@
     (when (policy bind (>= debug 1))
       (let ((args (functional-arg-documentation internal-fun)))
         (aver (not (eq args :unspecified)))
- (setf (entry-info-arguments info) args))
+ (setf (entry-info-arguments info) args)
+ ;; When the component is dumped, the arglists of the entry
+ ;; points will be dumped. If they contain values that need
+ ;; make-load-form processing then we need to do it now (bug
+ ;; 310132).
+ (maybe-emit-make-load-forms args))
       (setf (entry-info-type info) (type-specifier (leaf-type internal-fun)))))
   (values))

[Alastair Bridgewater (alastair-bridgewater)]

Fixed in 1.0.32.26.

[Tobias C. Rittweiler (tcr)]

Isn't this worth one, or two test cases? I wonder how one would best write test cases
involving the file-compiler. We really ough to have a COMPILE-FROM-STREAM which
has file-compilation semantics!