0.8.1.33:
[sbcl.git] / BUGS
diff --git a/BUGS b/BUGS
index 185c178..7586950 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -84,24 +84,7 @@ WORKAROUND:
      an error may be signalled at read time and it would be good if
      SBCL did it.
 
-  c: Reading of not initialized slot sometimes causes SEGV (for inline
-     accessors it is fixed, but out-of-line still do not perform type
-     check).
-
-  d:
-    (declaim (optimize (safety 3) (speed 1) (space 1)))
-    (defstruct foo
-      x y)
-    (defstruct (stringwise-foo (:include foo
-                                         (x "x" :type simple-string)
-                                         (y "y" :type simple-string))))
-    (defparameter *stringwise-foo*
-      (make-stringwise-foo))
-    (setf (foo-x *stringwise-foo*) 0)
-    (defun frob-stringwise-foo (sf)
-      (aref (stringwise-foo-x sf) 0))
-    (frob-stringwise-foo *stringwise-foo*)
-  SEGV.
+  d: (fixed in 0.8.1.5)
 
 7:
   The "compiling top-level form:" output ought to be condensed.
@@ -566,41 +549,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
@@ -700,11 +648,9 @@ WORKAROUND:
   propagation or with SSA, but consider
 
     (let ((x 0))
-      (loop (if (random-boolean)
-                (incf x 2)
-                (incf x 5))))
+      (loop (incf x 2)))
 
-  The careful type of X is {2k+5n} :-(. Is it really important to be
+  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"
@@ -1060,6 +1006,86 @@ 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 problem 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.)
+
+259:
+  (compile nil '(lambda () (aref (make-array 0) 0))) compiles without
+  warning.  Analogous cases with the index and length being equal and
+  greater than 0 are warned for; the problem here seems to be that the
+  type required for an array reference of this type is (INTEGER 0 (0))
+  which is canonicalized to NIL.
+
+260:
+  a.
+  (let* ((s (gensym))
+         (t1 (specifier-type s)))
+    (eval `(defstruct ,s))
+    (type= t1 (specifier-type s)))
+  => NIL, NIL
+
+  (fixed in 0.8.1.24)
+
+  b. The same for CSUBTYPEP.
+
+261:
+    * (let () (list (the (values &optional fixnum) (eval '(values)))))
+    debugger invoked on condition of type TYPE-ERROR:
+      The value NIL is not of type FIXNUM.
+
+262: "yet another bug in inline expansion of local functions"
+  Compiler fails on
+
+    (defun foo (x y)
+      (declare (integer x y))
+      (+ (block nil
+            (flet ((xyz (u)
+                     (declare (integer u))
+                     (if (> (1+ (the unsigned-byte u)) 0)
+                         (+ 1 u)
+                         (return (+ 38 (cos (/ u 78)))))))
+              (declare (inline xyz))
+              (return-from foo
+                (* (funcall (eval #'xyz) x)
+                   (if (> x 30)
+                       (funcall (if (> x 5) #'xyz #'identity)
+                                (+ x 13))
+                       38)))))
+         (sin (* x y))))
+
+  Urgh... It's time to write IR1-copier.
+
+262:
+  In 0.8.1.32:
+
+    * (ensure-generic-function 'foo)
+    #<STANDARD-GENERIC-FUNCTION FOO (0)>
+    * (defmethod foo (x) x)
+    debugger invoked on condition of type SIMPLE-ERROR:
+      The generic function #<STANDARD-GENERIC-FUNCTION FOO (0)> takes 0 required
+      arguments; was asked to find a method with specializers (#<BUILT-IN-CLASS T>)
+
+  AMOP seems to say that it should work (first ADD-METHOD initializes
+  GF lambda list).
+
+263:
+  :PREFIX, :PER-LINE-PREFIX and :SUFFIX arguments of
+  PPRINT-LOGICAL-BLOCK may be complex strings.
+
+  (fixed in 0.8.1.33)
+
 DEFUNCT CATEGORIES OF BUGS
   IR1-#:
     These labels were used for bugs related to the old IR1 interpreter.