X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=5d4a77904f3e832025da590dd767aff10beeec7b;hb=d323b0249b9b1e4a91ddf8716ac9185cd268d973;hp=c5172fa923c8ff2b79c4af5c8ca4333dd4b63bf4;hpb=4d5c5d322dcca0753474496cde44a9dbfe627496;p=sbcl.git

diff --git a/BUGS b/BUGS
index c5172fa..5d4a779 100644
--- a/BUGS
+++ b/BUGS
@@ -324,15 +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:
-	g: The type system [still] isn't all that smart about relationships
-	   between hairy types. [The original example from PVE was
-	   (SUBTYPEP 'CONS '(NOT ATOM)) => NIL, NIL, which was fixed
-	   by CSR in sbcl-0.7.1.28, but there are still
-           plenty of corner cases out there: (SUBTYPEP 'ATOM 'LIST)
-           returns NIL, NIL in sbcl-0.7.1.31.]
-
 51:
   miscellaneous errors reported by Peter Van Eynde July 25, 2000:
 	a: (PROGN
@@ -359,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.
 
@@ -1243,13 +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.
 
-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)
@@ -1281,6 +1251,66 @@ WORKAROUND:
   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.
+
 DEFUNCT CATEGORIES OF BUGS
   IR1-#:
     These labels were used for bugs related to the old IR1 interpreter.