0.8.2.7:

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index ca347e1..19ac95c 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -276,34 +276,6 @@ WORKAROUND:
   holding... * is not equivalent to T in many cases, such as 
     (VECTOR *) /= (VECTOR T).
 
   holding... * is not equivalent to T in many cases, such as 
     (VECTOR *) /= (VECTOR T).
 

-94a: 
-  Inconsistencies between derived and declared VALUES return types for
-  DEFUN aren't checked very well. E.g. the logic which successfully
-  catches problems like
-    (declaim (ftype (function (fixnum) float) foo))
-    (defun foo (x)
-      (declare (type integer x))
-      (values x)) ; wrong return type, detected, gives warning, good!
-  fails to catch
-    (declaim (ftype (function (t) (values t t)) bar))
-    (defun bar (x)
-      (values x)) ; wrong number of return values, no warning, bad!
-  The cause of this is seems to be that (1) the internal function 
-  VALUES-TYPES-EQUAL-OR-INTERSECT used to make the check handles its
-  arguments symmetrically, and (2) when the type checking code was
-  written back when when SBCL's code was still CMU CL, the intent
-  was that this case
-    (declaim (ftype (function (t) t) bar))
-    (defun bar (x)
-      (values x x)) ; wrong number of return values; should give warning?
-  not be warned for, because a two-valued return value is considered
-  to be compatible with callers who expects a single value to be
-  returned. That intent is probably not appropriate for modern ANSI
-  Common Lisp, but fixing this might be complicated because of other
-  divergences between auld-style and new-style handling of
-  multiple-VALUES types. (Some issues related to this were discussed
-  on cmucl-imp at some length sometime in 2000.)
-

 95:
   The facility for dumping a running Lisp image to disk gets confused
   when run without the PURIFY option, and creates an unnecessarily large
 95:
   The facility for dumping a running Lisp image to disk gets confused
   when run without the PURIFY option, and creates an unnecessarily large

@@ -846,22 +818,7 @@ WORKAROUND:
    Then (FOO #\1 *STANDARD-OUTPUT*) signals type error.
 
   (In 0.7.9.1 the result type is (FUNCTION * *), so Python does not
    Then (FOO #\1 *STANDARD-OUTPUT*) signals type error.
 
   (In 0.7.9.1 the result type is (FUNCTION * *), so Python does not

-  produce invalid code, but type checking is not accurate. Similar
-  problems exist with VALUES-TYPE-INTERSECTION.)
-
-220:
-  Sbcl 0.7.9 fails to compile
-
-  (multiple-value-call #'list
-    (the integer (helper))
-    nil)
-
-  Type check for INTEGER, the result of which serves as the first
-  argument of M-V-C, is inserted after evaluation of NIL. So arguments
-  of M-V-C are pushed in the wrong order. As a temporary workaround
-  type checking was disabled for M-V-Cs in 0.7.9.13. A better solution
-  would be to put the check between evaluation of arguments, but it
-  could be tricky to check result types of PROG1, IF etc.
+  produce invalid code, but type checking is not accurate.)

 
 233: bugs in constraint propagation
   a.
 
 233: bugs in constraint propagation
   a.

@@ -1011,7 +968,7 @@ WORKAROUND:
   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.
 
   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
+  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))).
 
   conflicts with derived type (VALUES SIMPLE-VECTOR &OPTIONAL)" during
   compiling (LAMBDA (V) (VALUES (SVREF V 0) (VECTOR-POP V))).
 

@@ -1021,8 +978,85 @@ WORKAROUND:
   currently checks for complex arrays seem to be performed by
   callees.)
 
   currently checks for complex arrays seem to be performed by
   callees.)
 

-258:
-  (fixed in 0.8.1.3)
+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.
+
+265:
+  SB-EXT:RUN-PROGRAM is currently non-functional on Linux/PPC;
+  attempting to use it leads to segmentation violations.  This is
+  probably because of a bogus implementation of
+  os_restore_fp_control().
+
+266:
+  David Lichteblau provided (sbcl-devel 2003-06-01) a patch to fix
+  behaviour of streams with element-type (SIGNED-BYTE 8).  The patch
+  looks reasonable, if not obviously correct; however, it caused the
+  PPC/Linux port to segfault during warm-init while loading
+  src/pcl/std-class.fasl.  A workaround patch was made, but it would
+  be nice to understand why the first patch caused problems, and to
+  fix the cause if possible.
+
+267:
+  In
+    (defun fact (x i)
+      (if (= x 0)
+          i
+          (fact (1- x) (* x i))))
+  sbcl does not convert the self-recursive call to a jump, though it
+  is allowed to by CLHS 3.2.2.3.  CMUCL, however, does perform this
+  optimization.
+
+268: "wrong free declaration scope"
+  The following code must signal type error:
+
+    (locally (declare (optimize (safety 3)))
+      (flet ((foo (x &optional (y (car x)))
+               (declare (optimize (safety 0)))
+               (list x y)))
+        (funcall (eval #'foo) 1)))

 
 DEFUNCT CATEGORIES OF BUGS
   IR1-#:
 
 DEFUNCT CATEGORIES OF BUGS
   IR1-#: