COMPILE does a better job if there is an additional lambda (result-type derivation lossage involving &more)

[Tobias C. Rittweiler]

CL-USER> (format t "~&The type is ~S~%"
                 (sb-kernel:%simple-fun-type
                  (compile nil `(lambda (x y &key k1)
                                  (declare (fixnum x y))
                                  (declare (boolean k1))
                                  (declare (ignore x y k1))
                                  t))))
The type is (FUNCTION (FIXNUM FIXNUM &KEY (:K1 (MEMBER NIL T))) *)
NIL
CL-USER> (format t "~&The type is ~S~%"
                 (sb-kernel:%simple-fun-type
                  (funcall (compile nil `(lambda ()
                                           (lambda (x y &key k1)
                                             (declare (fixnum x y))
                                             (declare (boolean k1))
                                             (declare (ignore x y k1))
                                             t))))))
The type is (FUNCTION (FIXNUM FIXNUM &KEY (:K1 (MEMBER NIL T)))
             (VALUES (MEMBER T) &OPTIONAL))
NIL

[Nikodemus Siivola (nikodemus)]

The problem seems to be that in the first case the tail-set of the main-entry for the optional dispatch is not the same one the TL-XEP has -- which is the one what gets the return type properly.

[Tobias C. Rittweiler (tcr)]

The problem is more general than indicated at first.

I stumbled upon this bug a few months later, and came to the
same conclusion as Nikodemus regarding symptomatic
reasons:

  http://article.gmane.org/gmane.lisp.steel-bank.devel/14430

[Nikodemus Siivola (nikodemus)]

This is related to bug 310173 and MAKE-TOPLEVEL-XEP not setting COMPONENT-REANALYZE to T, as far as I can tell.

[Nikodemus Siivola (nikodemus)]

In 1.0.44.4.