compile-file goes into debugger

[Stephen Westfold]

compile-file went into the debugger on a lisp file generated by our Specware system. I was able to reproduce it with a small file in a bare sncl containing the following three s-exprs:

(in-package :cl-user)

(defun ppTerm (x1) #'(lambda (x2) (ppTerm-1-1 x1 x2)))

(defun ppTerm-1-1 (tm yyy-1)
  (let ((mf (ppTerm tm)))
    (let ((ma (ppTerm tm)))
      (cons (funcall mf yyy-1)
        (funcall ma yyy-1)))))

Here is the transcript of compiling this:

> sbcl
This is SBCL 1.1.12, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (compile-file "~/Dropbox/SW/test/SBCLErr.lisp")

; compiling file "/Users/westfold/Dropbox/SW/test/SBCLErr.lisp" (written 17 SEP 2013 02:01:24 PM):
; compiling (IN-PACKAGE :CL-USER)
; compiling (DEFUN PPTERM ...)
; compiling (DEFUN PPTERM-1-1 ...)
debugger invoked on a TYPE-ERROR:
  The value
    #<CAST
      :%TYPE-CHECK T
      :VALUE #<SB-C::LVAR 1 {1002AD9BD3}>
      :ASSERTED-TYPE #<SB-KERNEL:VALUES-TYPE (VALUES FUNCTION &OPTIONAL)>
      :TYPE-TO-CHECK #<SB-KERNEL:VALUES-TYPE (VALUES FUNCTION &OPTIONAL)>
      {1002ADE853}>
  is not of type
    SB-C::REF.

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

(SB-C::COMBINATION-FUN-SOURCE-NAME #<SB-C::COMBINATION :FUN #<CAST :%TYPE-CHECK T :VALUE #<SB-C::LVAR 1 {1002AD9BD3}> :ASSERTED-TYPE #1=#<SB-KERNEL:VALUES-TYPE (VALUES FUNCTION &OPTIONAL)> :TYPE-TO-CHECK #1# {1002ADE853}> :ARGS (#<SB-C::REF :%SOURCE-NAME YYY-1 :LEAF #<SB-C::LAMBDA-VAR :%SOURCE-NAME YYY-1 {1002AD2DB3}> {1002AD7D83}>) {1002AD7B23}> NIL)
0]

> uname -a
Darwin dhcp216.kestrel.edu 12.5.0 Darwin Kernel Version 12.5.0: Mon Jul 29 16:33:49 PDT 2013; root:xnu-2050.48.11~1/RELEASE_X86_64 x86_64

[Paul Khuong (pvk)]

This definition of combination-fun-source-name looks through casts and fixes the bug. I'm more worried that we have anything but a reference to a leaf as a combination-fun; is that a newly broken invariant? Some bisection might help pinpoint whether this is a regression.

(defun combination-fun-source-name (combination &optional (errorp t))
  (let ((uses (principal-lvar-use (combination-fun combination)))
        leaf)
    (cond ((and (ref-p uses)
                (leaf-has-source-name-p (setf leaf (ref-leaf uses))))
           (values (leaf-source-name leaf) t))
          (errorp
           (aver (not "COMBINATION-FUN is not a ref to a nameful leaf")))
          (t
           (values nil nil)))))

[Lutz Euler (lutz-euler)]

I have bisected this (under Linux, x86-64) to:

12836ca105af62252aa0974c3f6992e60ce0ebf4 is the first bad commit
commit 12836ca105af62252aa0974c3f6992e60ce0ebf4
Author: Nikodemus Siivola <email address hidden>
Date: Thu Oct 14 16:32:51 2010 +0000

    1.0.43.57: better handling of derived function types

Do three years count as "newly"?

[Stas Boukarev (stassats)]

In 5ee931c9d00a2e7cd4b1de132b1e39e2f4cc840a