X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;ds=sidebyside;f=BUGS;h=a4ed57fade321fc4c6aeff8c3c86d9c0b3234abb;hb=f601ededaa926a19ca60f95e8bc6f7f0d966f9d1;hp=171061e476fd93c8b26c8bb26cb615fb51fcc149;hpb=b206788a30815e7cc363efebc0ead442c6b18dc3;p=sbcl.git

diff --git a/BUGS b/BUGS
index 171061e..a4ed57f 100644
--- a/BUGS
+++ b/BUGS
@@ -117,12 +117,6 @@ WORKAROUND:
 	  (during macroexpansion of IN-PACKAGE,
 	  during macroexpansion of DEFFOO)
 
-15:
-  (SUBTYPEP '(FUNCTION (T BOOLEAN) NIL)
-            '(FUNCTION (FIXNUM FIXNUM) NIL)) => T, T
-  (Also, when this is fixed, we can enable the code in PROCLAIM which 
-  checks for incompatible FTYPE redeclarations.)
-
 19:
   (I *think* this is a bug. It certainly seems like strange behavior. But
   the ANSI spec is scary, dark, and deep.. -- WHN)
@@ -217,14 +211,13 @@ WORKAROUND:
 
 46:
   type safety errors reported by Peter Van Eynde July 25, 2000:
-	c: (COERCE 'AND 'FUNCTION) returns something related to
-	   (MACRO-FUNCTION 'AND), but ANSI says it should raise an error.
 	k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is 
 	   not a binary input stream, but instead cheerfully reads from
 	   character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc").
 
 60:
   The debugger LIST-LOCATIONS command doesn't work properly.
+  (How should it work properly?)
 
 61:
   Compiling and loading
@@ -573,41 +566,6 @@ WORKAROUND:
 
   See also bugs #45.c and #183
 
-148:
-  In sbcl-0.7.1.3 on x86, COMPILE-FILE on the file
-    (in-package :cl-user)
-    (defvar *thing*)
-    (defvar *zoom*)
-    (defstruct foo bar bletch)
-    (defun %zeep ()
-      (labels ((kidify1 (kid)
-	         )
-               (kid-frob (kid)
-                 (if *thing*
-                    (setf sweptm
-              	           (m+ (frobnicate kid)
-				     sweptm))
-		    (kidify1 kid))))
-      (declare (inline kid-frob))
-      (map nil
-	   #'kid-frob
-	   (the simple-vector (foo-bar perd)))))
-  fails with
-    debugger invoked on condition of type TYPE-ERROR:
-      The value NIL is not of type SB-C::NODE.
-  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.
-
-  (Python LET-converts KIDIFY1 into KID-FROB, then tries to inline
-  expand KID-FROB into %ZEEP. Having partially done it, it sees a call
-  of KIDIFY1, which already does not exist. So it gives up on
-  expansion, leaving garbage consisting of infinished blocks of the
-  partially converted function.)
-
-  (due to reordering of the compiler this example is compiled
-  successfully by 0.7.14, but the bug probably remains)
-
 162:
   (reported by Robert E. Brown 2002-04-16) 
   When a function is called with too few arguments, causing the
@@ -703,6 +661,15 @@ WORKAROUND:
                (print (incf start 22))
                (print (incf start 26))))))
 
+  This example could be solved with clever enough constraint
+  propagation or with SSA, but consider
+
+    (let ((x 0))
+      (loop (incf x 2)))
+
+  The careful type of X is {2k} :-(. Is it really important to be
+  able to work with unions of many intervals?
+
 190: "PPC/Linux pipe? buffer? bug"
   In sbcl-0.7.6, the run-program.test.sh test script sometimes hangs
   on the PPC/Linux platform, waiting for a zombie env process.  This
@@ -731,7 +698,6 @@ WORKAROUND:
   c. the examples in CLHS 7.6.5.1 (regarding generic function lambda
      lists and &KEY arguments) do not signal errors when they should.
 
-
 201: "Incautious type inference from compound types"
   a. (reported by APD sbcl-devel 2002-09-17)
     (DEFUN FOO (X)
@@ -1057,6 +1023,24 @@ WORKAROUND:
 257:
   Complex array type does not have corresponding type specifier.
 
+  This is a problem because the compiler emits optimization notes when
+  you use a non-simple array, and without a type specifier for hairy
+  array types, there's no good way to tell it you're doing it
+  intentionally so that it should shut up and just compile the code.
+
+  Another poblem is confusing error message "asserted type ARRAY
+  conflicts with derived type (VALUES SIMPLE-VECTOR &OPTIONAL)" during
+  compiling (LAMBDA (V) (VALUES (SVREF V 0) (VECTOR-POP V))).
+
+  The last problem is that when type assertions are converted to type
+  checks, types are represented with type specifiers, so we could lose
+  complex attribute. (Now this is probably not important, because
+  currently checks for complex arrays seem to be performed by
+  callees.)
+
+258:
+  (fixed in 0.8.1.3)
+
 DEFUNCT CATEGORIES OF BUGS
   IR1-#:
     These labels were used for bugs related to the old IR1 interpreter.