1.0.15.3: Have PROBE-FILE return NIL whenever a truename can't be found.

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index 503fdc4..2496243 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -479,6 +479,11 @@ WORKAROUND:
                (print (incf start 22))
                (print (incf start 26))))))
 
+  [ Update: 1.0.14.36 improved this quite a bit (20-25%) by
+    eliminating useless work from PROPAGATE-FROM-SETS -- but as alluded
+    below, maybe we should be smarter about when to decide a derived
+    type is "good enough". ]
+
   This example could be solved with clever enough constraint
   propagation or with SSA, but consider
 
@@ -1612,22 +1617,6 @@ WORKAROUND:
   For some more details see comments for (define-alien-type-method
   (c-string :deport-gen) ...)  in host-c-call.lisp.
 
-402: "DECLAIM DECLARATION does not inform the PCL code-walker"
-  reported by Vincent Arkesteijn:
-
-  (declaim (declaration foo))
-  (defgeneric bar (x))
-  (defmethod bar (x)
-    (declare (foo x))
-    x)
-
-  ==> WARNING: The declaration FOO is not understood by
-      SB-PCL::SPLIT-DECLARATIONS.
-      Please put FOO on one of the lists SB-PCL::*NON-VAR-DECLARATIONS*,
-      SB-PCL::*VAR-DECLARATIONS-WITH-ARG*, or
-      SB-PCL::*VAR-DECLARATIONS-WITHOUT-ARG*.
-      (Assuming it is a variable declaration without argument).
-
 403: FORMAT/PPRINT-LOGICAL-BLOCK of CONDITIONs ignoring *PRINT-CIRCLE*
   In sbcl-0.9.13.34,
     (defparameter *c*
@@ -1729,6 +1718,10 @@ WORKAROUND:
                3: (SB-C::BOUND-FUNC ...)
                4: (SB-C::%SINGLE-FLOAT-DERIVE-TYPE-AUX ...)
 
+  These are now fixed, but (COERCE HUGE 'SINGLE-FLOAT) still signals a
+  type-error at runtime. The question is, should it instead signal a
+  floating-point overflow, or return an infinity?
+
 408: SUBTYPEP confusion re. OR of SATISFIES of not-yet-defined predicate
        As reported by Levente M\'{e}sz\'{a}ros sbcl-devel 2006-02-20,
                (aver (equal (multiple-value-list
@@ -1785,21 +1778,6 @@ WORKAROUND:
   implementation of read circularity, using a symbol as a marker for
   the previously-referenced object.
 
-413: type-errors in ROOM
-
-  (defvar *a* (make-array (expt 2 27)))
-  (room)
-
-  Causes a type-error on 32bit SBCL, as various byte-counts in ROOM
-  implementation overrun fixnums. 
-
-  This was fixed in 1.0.4.89, but the patch was reverted as it caused
-  ROOM to cons sufficiently to make running it in a loop deadly on
-  GENCGC: newly allocated objects survived to generation 1, where next
-  call to ROOM would see them, and allocate even more...
-
-  Reported by Faré Rideau on sbcl-devel.
-
 415: Issues creating large arrays on x86-64/Linux and x86/Darwin
 
    (make-array (1- array-dimension-limit))
@@ -1910,3 +1888,23 @@ Which should be fixed, the IR1, or the backend?
 behaves ...erratically. Reported by Kevin Reid on sbcl-devel
 2007-07-06. (We don't _have_ to check things like this, but we
 generally try to check returns in safe code, so we should here too.)
+
+423: TRULY-THE and *CHECK-CONSISTENCY*
+
+ The following signals errors due to TRULY-THEs in dead code:
+
+ (let ((sb-c::*check-consistency* t))
+  (handler-bind ((warning #'error))
+    (flet ((make-lambda (type)
+             `(lambda (x)
+                ((lambda (z)
+                   (if (listp z)
+                       (let ((q (truly-the list z)))
+                         (length q))
+                       (if (arrayp z)
+                           (let ((q (truly-the vector z)))
+                             (length q))
+                           (error "oops"))))
+                 (the ,type x)))))
+      (compile nil (make-lambda 'list))
+      (compile nil (make-lambda 'vector)))))