Perhaps any number of such consecutive lines ought to turn into a
single "compiling top-level forms:" line.
-19:
- (I *think* this is a bug. It certainly seems like strange behavior. But
- the ANSI spec is scary, dark, and deep.. -- WHN)
- (FORMAT NIL "~,1G" 1.4) => "1. "
- (FORMAT NIL "~3,1G" 1.4) => "1. "
-
27:
Sometimes (SB-EXT:QUIT) fails with
Argh! maximum interrupt nesting depth (4096) exceeded, exiting
a STYLE-WARNING for references to variables similar to locals might
be a good thing.)
-125:
- (as reported by Gabe Garza on cmucl-help 2001-09-21)
- (defvar *tmp* 3)
- (defun test-pred (x y)
- (eq x y))
- (defun test-case ()
- (let* ((x *tmp*)
- (func (lambda () x)))
- (print (eq func func))
- (print (test-pred func func))
- (delete func (list func))))
- Now calling (TEST-CASE) gives output
- NIL
- NIL
- (#<FUNCTION {500A9EF9}>)
- Evidently Python thinks of the lambda as a code transformation so
- much that it forgets that it's also an object.
-
135:
Ideally, uninterning a symbol would allow it, and its associated
FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However,
Expected: (2 6 15 38)
Got: ERROR
-317: "FORMAT of floating point numbers"
- reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
- test suite.
- (format nil "~1F" 10) => "0." ; "10." expected
- (format nil "~0F" 10) => "0." ; "10." expected
- (format nil "~2F" 1234567.1) => "1000000." ; "1234567." expected
- it would be nice if whatever fixed this also untangled the two
- competing implementations of floating point printing (Steele and
- White, and Burger and Dybvig) present in src/code/print.lisp
-
318: "stack overflow in compiler warning with redefined class"
reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
test suite.
(: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.
projects / sbcl.git / blobdiff