-149:
- (reported by Stig E Sandoe sbcl-devel 2002-02-02)
- In sbcl-0.7.1.13, compiling a DEFCLASS FOO form isn't enough to make
- the class known to the compiler for other forms compiled in the same
- file, so bogus warnings "undefined type: FOO" are generated, e.g.
- when compiling
- (in-package :cl-user)
- (defclass foo () ())
- (defun bar (x)
- (typep x 'foo))
-
-150:
- In sbcl-0.7.1.15, compiling this code
- (let* ()
- (flet ((wufn () (glorp table1 4.9)))
- (gleep *uustk* #'wufn "#1" (list)))
- (if (eql (lo foomax 3.2))
- (values)
- (error "not ~S" '(eql (lo foomax 3.2))))
- (values))
- causes a failure in SB-C::ADD-TEST-CONSTRAINTS:
- The value NIL is not of type SB-C::CONTINUATION.
- other notes:
- * The problem appears to be tied to the way that EQL is given only
- one argument, and goes away when we give EQL a second argument.
- * CMU CL 18c has this problem too, exercised by
- (compile nil
- '(lambda ()
- (let* ()
- (flet ((wufn () (glorp table1 4.9)))
- (gleep *uustk* #'wufn "#1" (list)))
- (if (eql (lo foomax 3.2))
- (values)
- (error "not ~S" '(eql (lo foomax 3.2))))
- (values))))
+153:
+ (essentially the same problem as a CMU CL bug reported by Martin
+ Cracauer on cmucl-imp 2002-02-19)
+ There is a hole in structure slot type checking. Compiling and LOADing
+ (declaim (optimize safety))
+ (defstruct foo
+ (bla 0 :type fixnum))
+ (defun f ()
+ (let ((foo (make-foo)))
+ (setf (foo-bla foo) '(1 . 1))
+ (format t "Is ~a of type ~a a cons? => ~a~%"
+ (foo-bla foo)
+ (type-of (foo-bla foo))
+ (consp (foo-bla foo)))))
+ (f)
+ should signal an error, but in sbcl-0.7.1.21 instead gives the output
+ Is (1 . 1) of type CONS a cons? => NIL
+ without signalling an error.
+
+154:
+ There's some sort of problem with aborting back out of the debugger
+ after a %DETECT-STACK-EXHAUSTION error in sbcl-0.7.1.38. In some cases
+ telling the debugger to ABORT doesn't get you back to the main REPL,
+ but instead just gives you another stack exhaustion error. The problem
+ doesn't occur in the trivial case
+ * (defun frob () (frob) (frob))
+ FROB
+ * (frob)
+ but it has happened in more complicated cases (which I haven't
+ figured out how to reproduce).
+
+155:
+ Executing
+ (defclass standard-gadget (basic-gadget) ())
+ (defclass basic-gadget () ())
+ gives an error:
+ The slot SB-PCL::DIRECT-SUPERCLASSES is unbound in the
+ object #<SB-PCL::STANDARD-CLASS "unbound">.
+ (reported by Brian Spilsbury sbcl-devel 2002-04-09)
+
+156:
+ FUNCTION-LAMBDA-EXPRESSION doesn't work right in 0.7.0 or 0.7.2.9:
+ * (function-lambda-expression #'(lambda (x) x))
+ debugger invoked on condition of type TYPE-ERROR:
+ The value NIL is not of type SB-C::DEBUG-SOURCE
+ (reported by Alexey Dejneka sbcl-devel 2002-04-12)
+
+157:
+ Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and
+ UPGRADED-COMPLEX-PART-TYPE should have an optional environment argument.
+ (reported by Alexey Dejneka sbcl-devel 2002-04-12)
+
+158:
+ Compiling the following code causes SBCL 0.7.2 to bug. This only
+ happens with optimization enabled, and only when the loop variable is
+ being incremented by more than 1.
+ (defun foo (array)
+ (declare (optimize (safety 0) (space 0) (debug 0) (speed 3)))
+ (loop for i from 0 to 10 by 2
+ do (foo (svref array i))) (svref array (1+ i)))
+ (reported by Eric Marsden sbcl-devel 2002-04-15)
+
+159:
+ * (lisp-implementation-version)
+ "0.7.2.6"
+ * (defstruct (foo
+ (:constructor make-foo (&key (bar nil bar-p)
+ &aux (baz (if bar-p bar 2)))))
+
+ bar
+ baz)
+ debugger invoked on condition of type SB-KERNEL::ARG-COUNT-ERROR:
+ error while parsing arguments to DESTRUCTURING-BIND:
+ invalid number of elements in
+ (BAR NIL BAR-P)
+ to satisfy lambda list
+ (SB-KERNEL::WOT &OPTIONAL (SB-KERNEL::DEF NIL SB-KERNEL::DEF-P)):
+ between 1 and 2 expected, but 3 found
+ (reported by Christophe Rhodes and Martin Atzmueller sbcl-devel
+ 2002-05-15)
+
+160:
+ USER-HOMEDIR-PATHNAME returns a pathname that SBCL can't do anything
+ with. Probably we should return an absolute physical pathname
+ instead. (Reported by Peter van Eynde sbcl-devel 2002-03-29)
+
+161:
+ Typep on certain SATISFIES types doesn't take account of the fact
+ that the function could cause an error; e.g. (TYPEP #\! '(SATISFIES
+ FBOUNDP)) raises an error when it should return NIL.
projects / sbcl.git / blobdiff