0.7.2.7:
[sbcl.git] / BUGS
diff --git a/BUGS b/BUGS
index 37156e8..502fd0b 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -137,6 +137,8 @@ WORKAROUND:
        (defclass ccc () ())
        (setf (find-class 'ccc1) (find-class 'ccc))
        (defmethod zut ((c ccc1)) 123)
+  In sbcl-0.7.1.13, this gives an error, 
+       There is no class named CCC1.
   DTC's recommended workaround from the mailing list 3 Mar 2000:
        (setf (pcl::find-class 'ccc1) (pcl::find-class 'ccc))
 
@@ -246,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:
@@ -328,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
@@ -527,18 +512,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
@@ -615,9 +588,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))
@@ -1059,20 +1029,6 @@ WORKAROUND:
   arguments in FLET/LABELS: it might be an old Python bug which is 
   only exercised by the new arrangement of the SBCL compiler.)
 
-132:
-  Trying to compile 
-    (DEFUN FOO () (CATCH 0 (PRINT 1331)))
-  gives an error
-    #<SB-C:TN '0!1> is not valid as the second argument to VOP:
-      SB-C:MAKE-CATCH-BLOCK,
-    since the TN's primitive type SB-VM::POSITIVE-FIXNUM doesn't allow
-    any of the SCs allowed by the operand restriction:
-     (SB-VM::DESCRIPTOR-REG)
-  The (CATCH 0 ...) construct is bad style (because of unportability
-  of EQ testing of numbers) but it is legal, and shouldn't cause an
-  internal compiler error. (This error occurs in sbcl-0.6.13 and in
-  0.pre7.86.flaky7.14.)
-
 135:
   Ideally, uninterning a symbol would allow it, and its associated
   FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However, 
@@ -1129,6 +1085,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:
@@ -1248,7 +1209,7 @@ WORKAROUND:
   it with only one entry in LEAF-REFS.
   
 148:
-  In sbcl-0.7.1.3 on x86, COMPILE-FILE on this file
+  In sbcl-0.7.1.3 on x86, COMPILE-FILE on the file
     (in-package :cl-user)
     (defvar *thing*)
     (defvar *zoom*)
@@ -1269,11 +1230,58 @@ WORKAROUND:
   fails with
     debugger invoked on condition of type TYPE-ERROR:
       The value NIL is not of type SB-C::NODE.
-  in IR1-OPTIMIZE-BLOCK.
-
+  The location of this failure has moved around as various related
+  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.
+
+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">
+
+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)
 
 DEFUNCT CATEGORIES OF BUGS
   IR1-#:
-    These numbers 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
+    These labels were used for bugs related to the old IR1 interpreter.
+    The # values reached 6 before the category was closed down.