+343: MOP:COMPUTE-DISCRIMINATING-FUNCTION overriding causes error
+ Even the simplest possible overriding of
+ COMPUTE-DISCRIMINATING-FUNCTION, suggested in the PCL implementation
+ as "canonical", does not work:
+ (defclass my-generic-function (standard-generic-function) ()
+ (:metaclass funcallable-standard-class))
+ (defmethod compute-discriminating-function ((gf my-generic-function))
+ (let ((dfun (call-next-method)))
+ (lambda (&rest args)
+ (apply dfun args))))
+ (defgeneric foo (x)
+ (:generic-function-class my-generic-function))
+ (defmethod foo (x) (+ x x))
+ (foo 5)
+ signals an error. This error is the same even if the LAMBDA is
+ replaced by (FUNCTION (SB-KERNEL:INSTANCE-LAMBDA ...)). Maybe the
+ SET-FUNCALLABLE-INSTANCE-FUN scary stuff in
+ src/code/target-defstruct.lisp is broken? This seems to be broken
+ in CMUCL 18e, so it's not caused by a recent change.
+
+344: more (?) ROOM T problems (possibly part of bug 108)
+ In sbcl-0.8.12.51, and off and on leading up to it, the
+ SB!VM:MEMORY-USAGE operations in ROOM T caused
+ unhandled condition (of type SB-INT:BUG):
+ failed AVER: "(SAP= CURRENT END)"
+ Several clever people have taken a shot at this without fixing
+ it; this time around (before sbcl-0.8.13 release) I (WHN) just
+ commented out the SB!VM:MEMORY-USAGE calls until someone figures
+ out how to make them work reliably with the rest of the GC.
+
+ (Note: there's at least one dubious thing in room.lisp: see the
+ comment in VALID-OBJ)
+
+346: alpha backtrace
+ In sbcl-0.8.13, all backtraces from errors caused by internal errors
+ on the alpha seem to have a "bogus stack frame".
+
+349: PPRINT-INDENT rounding implementation decisions
+ At present, pprint-indent (and indeed the whole pretty printer)
+ more-or-less assumes that it's using a monospace font. That's
+ probably not too silly an assumption, but one piece of information
+ the current implementation loses is from requests to indent by a
+ non-integral amount. As of sbcl-0.8.15.9, the system silently
+ truncates the indentation to an integer at the point of request, but
+ maybe the non-integral value should be propagated through the
+ pprinter and only truncated at output? (So that indenting by 1/2
+ then 3/2 would indent by two spaces, not one?)
+
+352: forward-referenced-class trouble
+ reported by Bruno Haible on sbcl-devel
+ (defclass c (a) ())
+ (setf (class-name (find-class 'a)) 'b)
+ (defclass a () (x))
+ (defclass b () (y))
+ (make-instance 'c)
+ Expected: an instance of c, with a slot named x
+ Got: debugger invoked on a SIMPLE-ERROR in thread 78906:
+ While computing the class precedence list of the class named C.
+ The class named B is a forward referenced class.
+ The class named B is a direct superclass of the class named C.
+
+353: debugger suboptimalities on x86
+ On x86 backtraces for undefined functions start with a bogus stack
+ frame, and backtraces for throws to unknown catch tags with a "no
+ debug information" frame. These are both due to CODE-COMPONENT-FROM-BITS
+ (used on non-x86 platforms) being a more complete solution then what
+ is done on x86.
+
+ On x86/linux large portions of tests/debug.impure.lisp have been commented
+ out as failures. The probable culprit for these problems is in x86-call-context
+ (things work fine on x86/freebsd).
+
+ More generally, the debugger internals suffer from excessive x86/non-x86
+ conditionalization and OAOOMization: refactoring the common parts would
+ be good.
+
+354: XEPs in backtraces
+ Under default compilation policy
+ (defun test ()
+ (throw :unknown t))
+ (test)
+ Has the XEP for TEST in the backtrace, not the TEST frame itself.
+ (sparc and x86 at least)
+
+ Since SBCL 0.8.20.1 this is hidden unless *SHOW-ENTRY-POINT-DETAILS*
+ is true (instead there appear two TEST frames at least on ppc). The
+ underlying cause seems to be that SB-C::TAIL-ANNOTATE will not merge
+ the tail-call for the XEP, since Python has by that time proved that
+ the function can never return; same happens if the function holds an
+ unconditional call to ERROR.
+
+355: change-class of generic-function
+ (reported by Bruno Haible)
+ The MOP doesn't support change-class on a generic-function. However, SBCL
+ apparently supports it, since it doesn't give an error or warning when doing
+ so so. Then, however, it produces wrong results for calls to this generic
+ function.
+ ;;; The effective-methods cache:
+ (progn
+ (defgeneric testgf35 (x))
+ (defmethod testgf35 ((x integer))
+ (cons 'integer (if (next-method-p) (call-next-method))))
+ (defmethod testgf35 ((x real))
+ (cons 'real (if (next-method-p) (call-next-method))))
+ (defclass customized5-generic-function (standard-generic-function)
+ ()
+ (:metaclass sb-pcl:funcallable-standard-class))
+ (defmethod sb-pcl:compute-effective-method ((gf customized5-generic-function) method-combination methods)
+ `(REVERSE ,(call-next-method)))
+ (list
+ (testgf35 3)
+ (progn
+ (change-class #'testgf35 'customized5-generic-function)
+ (testgf35 3))))
+ Expected: ((INTEGER REAL) (REAL INTEGER))
+ Got: ((INTEGER REAL) (INTEGER REAL))
+ ;;; The discriminating-function cache:
+ (progn
+ (defgeneric testgf36 (x))
+ (defmethod testgf36 ((x integer))
+ (cons 'integer (if (next-method-p) (call-next-method))))
+ (defmethod testgf36 ((x real))
+ (cons 'real (if (next-method-p) (call-next-method))))
+ (defclass customized6-generic-function (standard-generic-function)
+ ()
+ (:metaclass sb-pcl:funcallable-standard-class))
+ (defmethod sb-pcl:compute-discriminating-function ((gf customized6-generic-function))
+ (let ((orig-df (call-next-method)))
+ #'(lambda (&rest arguments)
+ (reverse (apply orig-df arguments)))))
+ (list
+ (testgf36 3)
+ (progn
+ (change-class #'testgf36 'customized6-generic-function)
+ (testgf36 3))))
+ Expected: ((INTEGER REAL) (REAL INTEGER))
+ Got: ((INTEGER REAL) (INTEGER REAL))
+
+356: PCL corruption
+ (reported by Bruno Haible)
+ After the "layout depth conflict" error, the CLOS is left in a state where
+ it's not possible to define new standard-class subclasses any more.
+ Test case:
+ (defclass prioritized-dispatcher ()
+ ((dependents :type list :initform nil)))
+ (defmethod sb-pcl:validate-superclass ((c1 sb-pcl:funcallable-standard-class)
+ (c2 (eql (find-class 'prioritized-dispatcher))))
+ t)
+ (defclass prioritized-generic-function (prioritized-dispatcher standard-generic-function)
+ ()
+ (:metaclass sb-pcl:funcallable-standard-class))
+ ;; ERROR, Quit the debugger with ABORT
+ (defclass typechecking-reader-class (standard-class)
+ ())
+ Expected: #<STANDARD-CLASS TYPECHECKING-READER-CLASS>
+ Got: ERROR "The assertion SB-PCL::WRAPPERS failed."
+
+357: defstruct inheritance of initforms
+ (reported by Bruno Haible)
+ When defstruct and defclass (with :metaclass structure-class) are mixed,
+ 1. some slot initforms are ignored by the DEFSTRUCT generated constructor
+ function, and
+ 2. all slot initforms are ignored by MAKE-INSTANCE. (This can be arguably
+ OK for initforms that were given in a DEFSTRUCT form, but for those
+ given in a DEFCLASS form, I think it qualifies as a bug.)
+ Test case:
+ (defstruct structure02a
+ slot1
+ (slot2 t)
+ (slot3 (floor pi)))
+ (defclass structure02b (structure02a)
+ ((slot4 :initform -44)
+ (slot5)
+ (slot6 :initform t)
+ (slot7 :initform (floor (* pi pi)))
+ (slot8 :initform 88))
+ (:metaclass structure-class))
+ (defstruct (structure02c (:include structure02b (slot8 -88)))
+ slot9
+ (slot10 t)
+ (slot11 (floor (exp 3))))
+ ;; 1. Form:
+ (let ((a (make-structure02c)))
+ (list (structure02c-slot4 a)
+ (structure02c-slot5 a)
+ (structure02c-slot6 a)
+ (structure02c-slot7 a)))
+ Expected: (-44 nil t 9)
+ Got: (SB-PCL::..SLOT-UNBOUND.. SB-PCL::..SLOT-UNBOUND..
+ SB-PCL::..SLOT-UNBOUND.. SB-PCL::..SLOT-UNBOUND..)
+ ;; 2. Form:
+ (let ((b (make-instance 'structure02c)))
+ (list (structure02c-slot2 b)
+ (structure02c-slot3 b)
+ (structure02c-slot4 b)
+ (structure02c-slot6 b)
+ (structure02c-slot7 b)
+ (structure02c-slot8 b)
+ (structure02c-slot10 b)
+ (structure02c-slot11 b)))
+ Expected: (t 3 -44 t 9 -88 t 20)
+ Got: (0 0 0 0 0 0 0 0)
+
+358: :DECLARE argument to ENSURE-GENERIC-FUNCTION
+ (reported by Bruno Haible)
+ According to ANSI CL, ensure-generic-function must accept a :DECLARE
+ keyword argument. In SBCL 0.8.16 it does not.
+ Test case:
+ (progn
+ (ensure-generic-function 'foo113 :declare '((optimize (speed 3))))
+ (sb-pcl:generic-function-declarations #'foo113))
+ Expected: ((OPTIMIZE (SPEED 3)))
+ Got: ERROR
+ Invalid initialization argument:
+ :DECLARE
+ in call for class #<SB-MOP:FUNCALLABLE-STANDARD-CLASS STANDARD-GENERIC-FUNCTION>.
+ See also:
+ The ANSI Standard, Section 7.1.2
+
+ Bruno notes: The MOP specifies that ensure-generic-function accepts :DECLARATIONS.
+ The easiest way to be compliant to both specs is to accept both (exclusively
+ or cumulatively).
+
+359: wrong default value for ensure-generic-function's :generic-function-class argument
+ (reported by Bruno Haible)
+ ANSI CL is silent on this, but the MOP's specification of ENSURE-GENERIC-FUNCTION says:
+ "The remaining arguments are the complete set of keyword arguments
+ received by ENSURE-GENERIC-FUNCTION."
+ and the spec of ENSURE-GENERIC-FUNCTION-USING-CLASS:
+ ":GENERIC-FUNCTION-CLASS - a class metaobject or a class name. If it is not
+ supplied, it defaults to the class named STANDARD-GENERIC-FUNCTION."
+ This is not the case in SBCL. Test case:
+ (defclass my-generic-function (standard-generic-function)
+ ()
+ (:metaclass sb-pcl:funcallable-standard-class))
+ (setf (fdefinition 'foo1)
+ (make-instance 'my-generic-function :name 'foo1))
+ (ensure-generic-function 'foo1
+ :generic-function-class (find-class 'standard-generic-function))
+ (class-of #'foo1)
+ ; => #<SB-MOP:FUNCALLABLE-STANDARD-CLASS STANDARD-GENERIC-FUNCTION>
+ (setf (fdefinition 'foo2)
+ (make-instance 'my-generic-function :name 'foo2))
+ (ensure-generic-function 'foo2)
+ (class-of #'foo2)
+ Expected: #<SB-MOP:FUNCALLABLE-STANDARD-CLASS STANDARD-GENERIC-FUNCTION>
+ Got: #<SB-MOP:FUNCALLABLE-STANDARD-CLASS MY-GENERIC-FUNCTION>
+
+360: CALL-METHOD not recognized in method-combination body
+ (reported by Bruno Haible)
+ This method combination, which adds 'redo' and 'return' restarts for each
+ method invocation to standard method combination, gives an error in SBCL.
+ (defun prompt-for-new-values ()
+ (format *debug-io* "~&New values: ")
+ (list (read *debug-io*)))
+ (defun add-method-restarts (form method)
+ (let ((block (gensym))
+ (tag (gensym)))
+ `(BLOCK ,block
+ (TAGBODY
+ ,tag
+ (RETURN-FROM ,block
+ (RESTART-CASE ,form
+ (METHOD-REDO ()
+ :REPORT (LAMBDA (STREAM) (FORMAT STREAM "Try calling ~S again." ,method))
+ (GO ,tag))
+ (METHOD-RETURN (L)
+ :REPORT (LAMBDA (STREAM) (FORMAT STREAM "Specify return values for ~S call." ,method))
+ :INTERACTIVE (LAMBDA () (PROMPT-FOR-NEW-VALUES))
+ (RETURN-FROM ,block (VALUES-LIST L)))))))))
+ (defun convert-effective-method (efm)
+ (if (consp efm)
+ (if (eq (car efm) 'CALL-METHOD)
+ (let ((method-list (third efm)))
+ (if (or (typep (first method-list) 'method) (rest method-list))
+ ; Reduce the case of multiple methods to a single one.
+ ; Make the call to the next-method explicit.
+ (convert-effective-method
+ `(CALL-METHOD ,(second efm)
+ ((MAKE-METHOD
+ (CALL-METHOD ,(first method-list) ,(rest method-list))))))
+ ; Now the case of at most one method.
+ (if (typep (second efm) 'method)
+ ; Wrap the method call in a RESTART-CASE.
+ (add-method-restarts
+ (cons (convert-effective-method (car efm))
+ (convert-effective-method (cdr efm)))
+ (second efm))
+ ; Normal recursive processing.
+ (cons (convert-effective-method (car efm))
+ (convert-effective-method (cdr efm))))))
+ (cons (convert-effective-method (car efm))
+ (convert-effective-method (cdr efm))))
+ efm))
+ (define-method-combination standard-with-restarts ()
+ ((around (:around))
+ (before (:before))
+ (primary () :required t)
+ (after (:after)))
+ (flet ((call-methods-sequentially (methods)
+ (mapcar #'(lambda (method)
+ `(CALL-METHOD ,method))
+ methods)))
+ (let ((form (if (or before after (rest primary))
+ `(MULTIPLE-VALUE-PROG1
+ (PROGN
+ ,@(call-methods-sequentially before)
+ (CALL-METHOD ,(first primary) ,(rest primary)))
+ ,@(call-methods-sequentially (reverse after)))
+ `(CALL-METHOD ,(first primary)))))
+ (when around
+ (setq form
+ `(CALL-METHOD ,(first around)
+ (,@(rest around) (MAKE-METHOD ,form)))))
+ (convert-effective-method form))))
+ (defgeneric testgf16 (x) (:method-combination standard-with-restarts))
+ (defclass testclass16a () ())
+ (defclass testclass16b (testclass16a) ())
+ (defclass testclass16c (testclass16a) ())
+ (defclass testclass16d (testclass16b testclass16c) ())
+ (defmethod testgf16 ((x testclass16a))
+ (list 'a
+ (not (null (find-restart 'method-redo)))
+ (not (null (find-restart 'method-return)))))
+ (defmethod testgf16 ((x testclass16b))
+ (cons 'b (call-next-method)))
+ (defmethod testgf16 ((x testclass16c))
+ (cons 'c (call-next-method)))
+ (defmethod testgf16 ((x testclass16d))
+ (cons 'd (call-next-method)))
+ (testgf16 (make-instance 'testclass16d))
+
+ Expected: (D B C A T T)
+ Got: ERROR CALL-METHOD outside of a effective method form
+
+ This is a bug because ANSI CL HyperSpec/Body/locmac_call-m__make-method
+ says
+ "The macro call-method invokes the specified method, supplying it with
+ arguments and with definitions for call-next-method and for next-method-p.
+ If the invocation of call-method is lexically inside of a make-method,
+ the arguments are those that were supplied to that method. Otherwise
+ the arguments are those that were supplied to the generic function."
+ and the example uses nothing more than these two cases (as you can see by
+ doing (trace convert-effective-method)).
+
+361: initialize-instance of standard-reader-method ignores :function argument
+ (reported by Bruno Haible)
+ Pass a custom :function argument to initialize-instance of a
+ standard-reader-method instance, but it has no effect.
+ ;; Check that it's possible to define reader methods that do typechecking.
+ (progn
+ (defclass typechecking-reader-method (sb-pcl:standard-reader-method)
+ ())
+ (defmethod initialize-instance ((method typechecking-reader-method) &rest initargs
+ &key slot-definition)
+ (let ((name (sb-pcl:slot-definition-name slot-definition))
+ (type (sb-pcl:slot-definition-type slot-definition)))
+ (apply #'call-next-method method
+ :function #'(lambda (args next-methods)
+ (declare (ignore next-methods))
+ (apply #'(lambda (instance)
+ (let ((value (slot-value instance name)))
+ (unless (typep value type)
+ (error "Slot ~S of ~S is not of type ~S: ~S"
+ name instance type value))
+ value))
+ args))
+ initargs)))
+ (defclass typechecking-reader-class (standard-class)
+ ())
+ (defmethod sb-pcl:validate-superclass ((c1 typechecking-reader-class) (c2 standard-class))
+ t)
+ (defmethod reader-method-class ((class typechecking-reader-class) direct-slot &rest args)
+ (find-class 'typechecking-reader-method))
+ (defclass testclass25 ()
+ ((pair :type (cons symbol (cons symbol null)) :initarg :pair :accessor testclass25-pair))
+ (:metaclass typechecking-reader-class))
+ (macrolet ((succeeds (form)
+ `(not (nth-value 1 (ignore-errors ,form)))))
+ (let ((p (list 'abc 'def))
+ (x (make-instance 'testclass25)))
+ (list (succeeds (make-instance 'testclass25 :pair '(seventeen 17)))
+ (succeeds (setf (testclass25-pair x) p))
+ (succeeds (setf (second p) 456))
+ (succeeds (testclass25-pair x))
+ (succeeds (slot-value x 'pair))))))
+ Expected: (t t t nil t)
+ Got: (t t t t t)
+
+ (inspect (first (sb-pcl:generic-function-methods #'testclass25-pair)))
+ shows that the method was created with a FAST-FUNCTION slot but with a
+ FUNCTION slot of NIL.
+
+362: missing error when a slot-definition is created without a name
+ (reported by Bruno Haible)
+ The MOP says about slot-definition initialization:
+ "The :NAME argument is a slot name. An ERROR is SIGNALled if this argument
+ is not a symbol which can be used as a variable name. An ERROR is SIGNALled
+ if this argument is not supplied."
+ Test case:
+ (make-instance (find-class 'sb-pcl:standard-direct-slot-definition))
+ Expected: ERROR
+ Got: #<SB-MOP:STANDARD-DIRECT-SLOT-DEFINITION NIL>
+
+363: missing error when a slot-definition is created with a wrong documentation object
+ (reported by Bruno Haible)
+ The MOP says about slot-definition initialization:
+ "The :DOCUMENTATION argument is a STRING or NIL. An ERROR is SIGNALled
+ if it is not. This argument default to NIL during initialization."
+ Test case:
+ (make-instance (find-class 'sb-pcl:standard-direct-slot-definition)
+ :name 'foo
+ :documentation 'not-a-string)
+ Expected: ERROR
+ Got: #<SB-MOP:STANDARD-DIRECT-SLOT-DEFINITION FOO>
+
+364: does not support class objects as specializer names
+ (reported by Bruno Haible)
+ According to ANSI CL 7.6.2, class objects are valid specializer names,
+ and "Parameter specializer names are used in macros intended as the
+ user-level interface (defmethod)". DEFMETHOD's syntax section doesn't
+ mention this possibility in the BNF for parameter-specializer-name;
+ however, this appears to be an editorial omission, since the CLHS
+ mentions issue CLASS-OBJECT-SPECIALIZER:AFFIRM as being approved
+ by X3J13. SBCL doesn't support it:
+ (defclass foo () ())
+ (defmethod goo ((x #.(find-class 'foo))) x)
+ Expected: #<STANDARD-METHOD GOO (#<STANDARD-CLASS FOO>)>
+ Got: ERROR "#<STANDARD-CLASS FOO> is not a legal class name."
+
+365: mixin on generic-function subclass
+ (reported by Bruno Haible)
+ a mixin class
+ (defclass prioritized-dispatcher ()
+ ((dependents :type list :initform nil)))
+ on a generic-function subclass:
+ (defclass prioritized-generic-function (prioritized-dispatcher standard-generic-function)
+ ()
+ (:metaclass sb-pcl:funcallable-standard-class))
+ SBCL gives an error on this, telling to define a method on SB-MOP:VALIDATE-SUPERCLASS. If done,
+ (defmethod sb-pcl:validate-superclass ((c1 sb-pcl:funcallable-standard-class)
+ (c2 (eql (find-class 'prioritized-dispatcher))))
+ t)
+ then, however,
+ (defclass prioritized-generic-function (prioritized-dispatcher standard-generic-function)
+ ()
+ (:metaclass sb-pcl:funcallable-standard-class))
+ => debugger invoked on a SIMPLE-ERROR in thread 6687:
+ layout depth conflict: #(#<SB-KERNEL:LAYOUT for T {500E1E9}> ...)
+
+ Further discussion on this: http://thread.gmane.org/gmane.lisp.steel-bank.general/491
+
+366: cannot define two generic functions with user-defined class
+ (reported by Bruno Haible)
+ it is possible to define one generic function class and an instance
+ of it. But attempting to do the same thing again, in the same session,
+ leads to a "Control stack exhausted" error. Test case:
+ (defclass my-generic-function-1 (standard-generic-function)
+ ()
+ (:metaclass sb-pcl:funcallable-standard-class))
+ (defgeneric testgf-1 (x) (:generic-function-class my-generic-function-1)
+ (:method ((x integer)) (cons 'integer nil)))
+ (defclass my-generic-function-2 (standard-generic-function)
+ ()
+ (:metaclass sb-pcl:funcallable-standard-class))
+ (defgeneric testgf-2 (x) (:generic-function-class my-generic-function-2)
+ (:method ((x integer)) (cons 'integer nil)))
+ => SB-KERNEL::CONTROL-STACK-EXHAUSTED
+
+367: TYPE-ERROR at compile time, undetected TYPE-ERROR at runtime
+ This test program
+ (declaim (optimize (safety 3) (debug 2) (speed 2) (space 1)))
+ (defstruct e367)
+ (defstruct i367)
+ (defstruct g367
+ (i367s (make-array 0 :fill-pointer t) :type (or (vector i367) null)))
+ (defstruct s367
+ (g367 (error "missing :G367") :type g367 :read-only t))
+ ;;; In sbcl-0.8.18, commenting out this (DECLAIM (FTYPE ... R367))
+ ;;; gives an internal error at compile time:
+ ;;; The value #<SB-KERNEL:NAMED-TYPE NIL> is not of
+ ;;; type SB-KERNEL:VALUES-TYPE.
+ (declaim (ftype (function ((vector i367) e367) (or s367 null)) r367))
+ (declaim (ftype (function ((vector e367)) (values)) h367))
+ (defun frob (v w)
+ (let ((x (g367-i367s (make-g367))))
+ (let* ((y (or (r367 x w)
+ (h367 x)))
+ (z (s367-g367 y)))
+ (format t "~&Y=~S Z=~S~%" y z)
+ (g367-i367s z))))
+ (defun r367 (x y) (declare (ignore x y)) nil)
+ (defun h367 (x) (declare (ignore x)) (values))
+ ;;; In sbcl-0.8.18, executing this form causes an low-level error
+ ;;; segmentation violation at #X9B0E1F4
+ ;;; (instead of the TYPE-ERROR that one might like).
+ (frob 0 (make-e367))
+ can be made to cause two different problems, as noted in the comments:
+ bug 367a: Compile and load the file. No TYPE-ERROR is signalled at
+ run time (in the (S367-G367 Y) form of FROB, when Y is NIL
+ instead of an instance of S367). Instead (on x86/Linux at least)
+ we end up with a segfault.
+ bug 367b: Comment out the (DECLAIM (FTYPE ... R367)), and compile
+ the file. The compiler fails with TYPE-ERROR at compile time.
+
+368: miscompiled OR (perhaps related to bug 367)
+ Trying to relax type declarations to find a workaround for bug 367,
+ it turns out that even when the return type isn't declared (or
+ declared to be T, anyway) the system remains confused about type
+ inference in code similar to that for bug 367:
+ (in-package :cl-user)
+ (declaim (optimize (safety 3) (debug 2) (speed 2) (space 1)))
+ (defstruct e368)
+ (defstruct i368)
+ (defstruct g368
+ (i368s (make-array 0 :fill-pointer t) :type (or (vector i368) null)))
+ (defstruct s368
+ (g368 (error "missing :G368") :type g368 :read-only t))
+ (declaim (ftype (function (fixnum (vector i368) e368) t) r368))
+ (declaim (ftype (function (fixnum (vector e368)) t) h368))
+ (defparameter *h368-was-called-p* nil)
+ (defun nsu (vertices e368)
+ (let ((i368s (g368-i368s (make-g368))))
+ (let ((fuis (r368 0 i368s e368)))
+ (format t "~&FUIS=~S~%" fuis)
+ (or fuis (h368 0 i368s)))))
+ (defun r368 (w x y)
+ (declare (ignore w x y))
+ nil)
+ (defun h368 (w x)
+ (declare (ignore w x))
+ (setf *h368-was-called-p* t)
+ (make-s368 :g368 (make-g368)))
+ (trace r368 h368)
+ (format t "~&calling NSU~%")
+ (let ((nsu (nsu #() (make-e368))))
+ (format t "~&NSU returned ~S~%" nsu)
+ (format t "~&*H368-WAS-CALLED-P*=~S~%" *h368-was-called-p*)
+ (assert (s368-p nsu))
+ (assert *h368-was-called-p*))
+ In sbcl-0.8.18, both ASSERTs fail, and (DISASSEMBLE 'NSU) shows
+ that no call to H368 is compiled.
+
+369: unlike-an-intersection behavior of VALUES-TYPE-INTERSECTION
+ In sbcl-0.8.18.2, the identity $(x \cap y \cap y)=(x \cap y)$
+ does not hold for VALUES-TYPE-INTERSECTION, even for types which
+ can be intersected exactly, so that ASSERTs fail in this test case:
+ (in-package :cl-user)
+ (let ((types (mapcar #'sb-c::values-specifier-type
+ '((values (vector package) &optional)
+ (values (vector package) &rest t)
+ (values (vector hash-table) &rest t)
+ (values (vector hash-table) &optional)
+ (values t &optional)
+ (values t &rest t)
+ (values nil &optional)
+ (values nil &rest t)
+ (values sequence &optional)
+ (values sequence &rest t)
+ (values list &optional)
+ (values list &rest t)))))
+ (dolist (x types)
+ (dolist (y types)
+ (let ((i (sb-c::values-type-intersection x y)))
+ (assert (sb-c::type= i (sb-c::values-type-intersection i x)))
+ (assert (sb-c::type= i (sb-c::values-type-intersection i y)))))))
+
+370: reader misbehaviour on large-exponent floats
+ (read-from-string "1.0s1000000000000000000000000000000000000000")
+ causes the reader to attempt to create a very large bignum (which it
+ will then attempt to coerce to a rational). While this isn't
+ completely wrong, it is probably not ideal -- checking the floating
+ point control word state and then returning the relevant float
+ (most-positive-short-float or short-float-infinity) or signalling an
+ error immediately would seem to make more sense.
+
+372: floating-point overflow not signalled on ppc/darwin
+ The following assertions in float.pure.lisp fail on ppc/darwin
+ (Mac OS X version 10.3.7):
+ (assert (raises-error? (scale-float 1.0 most-positive-fixnum)
+ floating-point-overflow))
+ (assert (raises-error? (scale-float 1.0d0 (1+ most-positive-fixnum))
+ floating-point-overflow)))
+ as the SCALE-FLOAT just returns
+ #.SB-EXT:SINGLE/DOUBLE-FLOAT-POSITIVE-INFINITY. These tests have been
+ disabled on Darwin for now.
+
+377: Memory fault error reporting
+ On those architectures where :C-STACK-IS-CONTROL-STACK is in
+ *FEATURES*, we handle SIG_MEMORY_FAULT (SEGV or BUS) on an altstack,
+ so we cannot handle the signal directly (as in interrupt_handle_now())
+ in the case when the signal comes from some external agent (the user
+ using kill(1), or a fault in some foreign code, for instance). As
+ of sbcl-0.8.20.20, this is fixed by calling
+ arrange_return_to_lisp_function() to a new error-signalling
+ function, but as a result the error reporting is poor: we cannot
+ even tell the user at which address the fault occurred. We should
+ arrange such that arguments can be passed to the function called from
+ arrange_return_to_lisp_function(), but this looked hard to do in
+ general without suffering from memory leaks.
+
+379: TRACE :ENCAPSULATE NIL broken on ppc/darwin
+ See commented-out test-case in debug.impure.lisp.
+
+380: Accessor redefinition fails because of old accessor name
+ When redefining an accessor, SB-PCL::FIX-SLOT-ACCESSORS may try to
+ find the generic function named by the old accessor name using
+ ENSURE-GENERIC-FUNCTION and then remove the old accessor's method in
+ the GF. If the old name does not name a function, or if the old name
+ does not name a generic function, no attempt to find the GF or remove
+ any methods is made.
+
+ However, if an unrelated GF with an incompatible lambda list exists,
+ the class redefinition will fail when SB-PCL::REMOVE-READER-METHOD
+ tries to find and remove a method with an incompatible lambda list
+ from the unrelated generic function.
+
+381: incautious calls to EQUAL in fasl dumping
+ Compiling
+ (frob #(#1=(a #1#)))
+ (frob #(#1=(b #1#)))
+ (frob #(#1=(a #1#)))
+ in sbcl-0.9.0 causes CONTROL-STACK-EXHAUSTED. My (WHN) impression
+ is that this follows from the use of (MAKE-HASH-TABLE :TEST 'EQUAL)
+ to detect sharing, in which case fixing it might require either
+ getting less ambitious about detecting shared list structure, or
+ implementing the moral equivalent of EQUAL hash tables in a
+ cycle-tolerant way.
+
+382: externalization unexpectedly changes array simplicity
+ COMPILE-FILE and LOAD
+ (defun foo ()
+ (let ((x #.(make-array 4 :fill-pointer 0)))
+ (values (eval `(typep ',x 'simple-array))
+ (typep x 'simple-array))))
+ then (FOO) => T, NIL.
+
+ Similar problems exist with SIMPLE-ARRAY-P, ARRAY-HEADER accessors
+ and all array dimension functions.
+
+383: ASH'ing non-constant zeros
+ Compiling
+ (lambda (b)
+ (declare (type (integer -2 14) b))
+ (declare (ignorable b))
+ (ash (imagpart b) 57))
+ on PPC (and other platforms, presumably) gives an error during the
+ emission of FASH-ASH-LEFT/FIXNUM=>FIXNUM as the assembler attempts to
+ stuff a too-large constant into the immediate field of a PPC
+ instruction. Either the VOP should be fixed or the compiler should be
+ taught how to transform this case away, paying particular attention
+ to side-effects that might occur in the arguments to ASH.
+
+384: Compiler runaway on very large character types
+
+ (compile nil '(lambda (x)
+ (declare (type (member #\a 1) x))
+ (the (member 1 nil) x)))
+
+ The types apparently normalize into a very large type, and the compiler
+ gets lost in REMOVE-DUPLICATES. Perhaps the latter should use
+ a better algorithm (one based on hash tables, say) on very long lists
+ when :TEST has its default value?
+
+ A simpler example:
+
+ (compile nil '(lambda (x) (the (not (eql #\a)) x)))
+
+ (partially fixed in 0.9.3.1, but a better representation for these
+ types is needed.)
+
+385:
+ (format nil "~4,1F" 0.001) => "0.00" (should be " 0.0");
+ (format nil "~4,1@F" 0.001) => "+.00" (should be "+0.0").
+
+386: SunOS/x86 stack exhaustion handling broken
+ According to <http://alfa.s145.xrea.com/sbcl/solaris-x86.html>, the
+ stack exhaustion checking (implemented with a write-protected guard
+ page) does not work on SunOS/x86.
+
+387:
+ 12:10 < jsnell> the package-lock test is basically due to a change in the test
+ behaviour when you install a handler for error around it. I
+ thought I'd disabled the test for now, but apparently that was
+ my imagination
+ 12:19 < Xophe> jsnell: ah, I see the problem in the package-locks stuff
+ 12:19 < Xophe> it's the same problem as we had with compiler-error conditions
+ 12:19 < Xophe> the thing that's signalled up and down the stack is a subtype of
+ ERROR, where it probably shouldn't be
+
+388:
+ (found by Dmitry Bogomolov)
+
+ (defclass foo () ((x :type (unsigned-byte 8))))
+ (defclass bar () ((x :type symbol)))
+ (defclass baz (foo bar) ())
+
+ causes error
+
+ SB-PCL::SPECIALIZER-APPLICABLE-USING-TYPE-P cannot handle the second argument
+ (UNSIGNED-BYTE 8).
+
+389:
+ (reported several times on sbcl-devel, by Rick Taube, Brian Rowe and
+ others)
+
+ ROUND-NUMERIC-BOUND assumes that float types always have a FORMAT
+ specifying whether they're SINGLE or DOUBLE. This is true for types
+ computed by the type system itself, but the compiler type derivation
+ short-circuits this and constructs non-canonical types. A temporary
+ fix was made to ROUND-NUMERIC-BOUND for the sbcl-0.9.6 release, but
+ the right fix is to remove the abstraction violation in the
+ compiler's type deriver.
+
+393: Wrong error from methodless generic function
+ (DEFGENERIC FOO (X))
+ (FOO 1 2)
+ gives NO-APPLICABLE-METHOD rather than an argument count error.
+
+394: (SETF CLASS-NAME)/REINITIALIZE-INSTANCE bug
+ (found by PFD ansi-tests)
+ in sbcl-0.9.7.15, (SETF (CLASS-NAME <class>) 'NIL) causes
+ (FIND-CLASS NIL) to return a #<STANDARD-CLASS NIL>.
+
+395: Unicode and streams
+ One of the remaining problems in SBCL's Unicode support is the lack
+ of generality in certain streams.
+ a. FILL-POINTER-STREAMs: SBCL refuses to write (e.g. using FORMAT)
+ to streams made from strings that aren't character strings with
+ fill-pointers:
+ (let ((v (make-array 5 :fill-pointer 0 :element-type 'standard-char)))
+ (format v "foo")
+ v)
+ should return a non-simple base string containing "foo" but
+ instead errors.
+
+ (reported on sbcl-help by "tichy")
+
+396: block-compilation bug
+ (let ((x 1))
+ (dotimes (y 10)
+ (let ((y y))
+ (when (funcall (eval #'(lambda (x) (eql x 2))) y)
+ (defun foo (z)
+ (incf x (incf y z))))))
+ (defun bar (z)
+ (foo z)
+ (values x)))
+ (bar 1) => 11, should be 4.
+
+397: SLEEP accuracy
+ The more interrupts arrive the less accurate SLEEP's timing gets.
+ (time (sb-thread:terminate-thread
+ (prog1 (sb-thread:make-thread (lambda ()
+ (loop
+ (princ #\!)
+ (force-output)
+ (sb-ext:gc))))
+ (sleep 1))))
+
+398: GC-unsafe SB-ALIEN string deporting
+ Translating a Lisp string to an alien string by taking a SAP to it
+ as done by the :DEPORT-GEN methods for C-STRING and UTF8-STRING
+ is not safe, since the Lisp string can move. For example the
+ following code will fail quickly on both cheneygc and pre-0.9.8.19
+ GENCGC:
+
+ (setf (bytes-consed-between-gcs) 4096)
+ (define-alien-routine "strcmp" int (s1 c-string) (s2 c-string))
+
+ (loop
+ (let ((string "hello, world"))
+ (assert (zerop (strcmp string string)))))
+
+ (This will appear to work on post-0.9.8.19 GENCGC, since
+ the GC no longer zeroes memory immediately after releasing
+ it after a minor GC. Either enabling the READ_PROTECT_FREE_PAGES
+ #define in gencgc.c or modifying the example so that a major
+ GC will occasionally be triggered would unmask the bug.)
+
+ On cheneygc the only solution would seem to be allocating some alien
+ memory, copying the data over, and arranging that it's freed once we
+ return. For GENCGC we could instead try to arrange that the string
+ from which the SAP is taken is always pinned.
+
+ For some more details see comments for (define-alien-type-method
+ (c-string :deport-gen) ...) in host-c-call.lisp.
+
+401: "optimizer runaway on bad constant type specifiers in TYPEP"
+ In 0.9.12.3 (and probably many earlier versions), COMPILE-FILE on
+ (defun ouch401 ()
+ (etypecase (signum (- x y))
+ ((-1 nil))
+ ((0 1) (oops "shouldn't happen"))))
+ or just
+ (defun foo401 (x)
+ (typep x '(-1 nil)))
+ spins emitting what seems to be an endless series of compiler
+ warnings like
+ ; --> TYPEP TYPEP TYPEP TYPEP TYPEP TYPEP TYPEP TYPEP TYPEP TYPEP
+ ; --> TYPEP TYPEP TYPEP TYPEP TYPEP TYPEP TYPEP TYPEP TYPEP TYPEP
+ ; --> TYPEP
+ ; ==>
+ ; (TYPEP SB-C::OBJECT '(-1 NIL))
+ ;
+ ; caught WARNING:
+ ; illegal type specifier for TYPEP: (-1 NIL)
projects / sbcl.git / blobdiff