0.7.2.12:
[sbcl.git] / BUGS
diff --git a/BUGS b/BUGS
index 7f00c53..77a6771 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -248,12 +248,6 @@ WORKAROUND:
   ANSI spec, bare 'MEMBER, 'AND, and 'OR are not legal types, CMUCL
   (and now SBCL) interpret them as legal types.
 
-44:
-  ANSI specifies DEFINE-SYMBOL-MACRO, but it's not defined in SBCL.
-  CMU CL added it ca. Aug 13, 2000, after some discussion on the mailing
-  list, and it is probably possible to use substantially the same 
-  patches to add it to SBCL.
-
 45:
   a slew of floating-point-related errors reported by Peter Van Eynde
   on July 25, 2000:
@@ -330,17 +324,6 @@ WORKAROUND:
        c: SYMBOL-MACROLET should signal PROGRAM-ERROR if something
           it binds is declared SPECIAL inside.
 
-50:
-  type system errors reported by Peter Van Eynde July 25, 2000:
-       c: (SUBTYPEP '(INTEGER (0) (0)) 'NIL) dies with nested errors.
-       d: In general, the system doesn't like '(INTEGER (0) (0)) -- it
-          blows up at the level of SPECIFIER-TYPE with
-          "Lower bound (0) is greater than upper bound (0)." Probably
-          SPECIFIER-TYPE should return the NIL type instead.
-       g: The type system isn't all that smart about relationships
-          between hairy types, as shown in the type.erg test results,
-          e.g. (SUBTYPEP 'CONS '(NOT ATOM)) => NIL, NIL.
-
 51:
   miscellaneous errors reported by Peter Van Eynde July 25, 2000:
        a: (PROGN
@@ -367,20 +350,6 @@ WORKAROUND:
   The implementation of #'+ returns its single argument without
   type checking, e.g. (+ "illegal") => "illegal".
 
-58:
-  (SUBTYPEP '(AND ZILCH INTEGER) 'ZILCH) => NIL, NIL
-  Note: I looked into fixing this in 0.6.11.15, but gave up. The
-  problem seems to be that there are two relevant type methods for
-  the subtypep operation, HAIRY :COMPLEX-SUBTYPEP-ARG2 and
-  INTERSECTION :COMPLEX-SUBTYPEP-ARG1, and only the first is
-  called. This could be fixed, but type dispatch is messy and
-  confusing enough already, I don't want to complicate it further.
-  Perhaps someday we can make CLOS cross-compiled (instead of compiled
-  after bootstrapping) so that we don't need to have the type system
-  available before CLOS, and then we can rewrite the type methods to
-  CLOS methods, and then expressing the solutions to stuff like this
-  should become much more straightforward. -- WHN 2001-03-14
-
 60:
   The debugger LIST-LOCATIONS command doesn't work properly.
 
@@ -529,18 +498,6 @@ WORKAROUND:
   it should probably look at the class name, the way that it does
   for STRUCTURE-OBJECTs.
 
-69:
-  As reported by Martin Atzmueller on the sbcl-devel list 2000-11-22,
-  > There remains one issue, that is a bug in SBCL:
-  > According to my interpretation of the spec, the ":" and "@" modifiers
-  > should appear _after_ the comma-seperated arguments.
-  > Well, SBCL (and CMUCL for that matter) accept 
-  > (ASSERT (STRING= (FORMAT NIL "~:8D" 1) "   1"))
-  > where the correct way (IMHO) should be
-  > (ASSERT (STRING= (FORMAT NIL "~8:D" 1) "   1"))
-  Probably SBCL should stop accepting the "~:8D"-style format arguments,
-  or at least issue a warning.
-
 70:
   (probably related to bug #65; maybe related to bug #109)
   The compiler doesn't like &OPTIONAL arguments in LABELS and FLET
@@ -617,9 +574,6 @@ WORKAROUND:
   it would decrease efficiency more than is probably necessary. Perhaps
   using some sort of accept/reject method would be better.
 
-84:
-  (SUBTYPEP '(SATISFIES SOME-UNDEFINED-FUN) NIL)=>NIL,T (should be NIL,NIL)
-
 85:
   Internally the compiler sometimes evaluates
     (sb-kernel:type/= (specifier-type '*) (specifier-type t))
@@ -1117,6 +1071,11 @@ WORKAROUND:
   T
   T
 
+  This is probably due to underzealous clearing of the type caches; a
+  brute-force solution in that case would be to make a defclass expand
+  into something that included a call to SB-KERNEL::CLEAR-TYPE-CACHES,
+  but there may be a better solution.
+
 141: 
   Pretty-printing nested backquotes doesn't work right, as 
   reported by Alexey Dejneka sbcl-devel 2002-01-13:
@@ -1261,44 +1220,6 @@ WORKAROUND:
   issues were cleaned up. As of sbcl-0.7.1.9, it occurs in 
   NODE-BLOCK called by LAMBDA-COMPONENT called by IR2-CONVERT-CLOSURE.
 
-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))))
-
-151:
-  From the ANSI description of GET-DISPATCH-MACRO-CHARACTER, it
-  should return NIL when there is no definition, e.g.
-    (GET-DISPATCH-MACRO-CHARACTER #\# #\{) => NIL
-  Instead, in sbcl-0.7.1.17 it returns
-    #<FUNCTION "top level local call SB!IMPL::DISPATCH-CHAR-ERROR">
-
-152:
-  Undefined functions are supposed to be reported as UNDEFINED-FUNCTION
-  conditions, inheriting from CELL-ERROR. Instead sbcl-0.7.1.19 reports
-  them as TYPE-ERRORs (reporting the problem as something not being
-  coerceable to a function).
-
 153:
   (essentially the same problem as a CMU CL bug reported by Martin
   Cracauer on cmucl-imp 2002-02-19)
@@ -1318,8 +1239,70 @@ WORKAROUND:
     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)
+
 
 DEFUNCT CATEGORIES OF BUGS
   IR1-#:
     These labels were used for bugs related to the old IR1 interpreter.
-    The # values reached 6 before the category was closed down.
\ No newline at end of file
+    The # values reached 6 before the category was closed down.