1.0.23.58: bug 405 has been fixed a while now

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index d7ecde8..414d010 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -606,21 +606,14 @@ WORKAROUND:
      can erroneously return T.
 
 215: ":TEST-NOT handling by functions"
-  a. FIND and POSITION currently signal errors when given non-NIL for
-     both their :TEST and (deprecated) :TEST-NOT arguments, but by
-     ANSI 17.2 "the consequences are unspecified", which by ANSI 1.4.2
-     means that the effect is "unpredictable but harmless".  It's not
-     clear what that actually means; it may preclude conforming
-     implementations from signalling errors.
-  b. COUNT, REMOVE and the like give priority to a :TEST-NOT argument
-     when conflict occurs.  As a quality of implementation issue, it
-     might be preferable to treat :TEST and :TEST-NOT as being in some
-     sense the same &KEY, and effectively take the first test function in
-     the argument list.
-  c. Again, a quality of implementation issue: it would be good to issue a
-     STYLE-WARNING at compile-time for calls with :TEST-NOT, and a
-     WARNING for calls with both :TEST and :TEST-NOT; possibly this
-     latter should be WARNed about at execute-time too.
+  
+  We should verify that our handling of :TEST-NOT and :TEST is consistent
+  for all functions that accept them: that is, signal an error if both
+  are specified.
+
+  Similarly, a compile-time full warning for calls with both would be good.
+
+  We might also consider a compile-time style warning for :TEST-NOT.
 
 216: "debugger confused by frames with invalid number of arguments"
   In sbcl-0.7.8.51, executing e.g. (VECTOR-PUSH-EXTEND T), BACKTRACE, Q
@@ -841,14 +834,6 @@ WORKAROUND:
 
   (fixed in 0.8.2.51, but a test case would be good)
 
-276:
-  b. The same as in a., but using MULTIPLE-VALUE-SETQ instead of SETQ.
-  c. (defvar *faa*)
-     (defmethod faa ((*faa* double-float))
-           (set '*faa* (when (< *faa* 0) (- *faa*)))
-           (1+ *faa*))
-     (faa 1d0) => type error
-
 279: type propagation error -- correctly inferred type goes astray?
   In sbcl-0.8.3 and sbcl-0.8.1.47, the warning
        The binding of ABS-FOO is a (VALUES (INTEGER 0 0)
@@ -1613,17 +1598,6 @@ WORKAROUND:
   perhaps because CLISP has shuffled the clauses into an 
   ANSI-compliant order before proceeding.
 
-405: a TYPE-ERROR in MERGE-LETS exercised at DEBUG 3
-  In sbcl-0.9.16.21 on linux/86, compiling 
-    (declaim (optimize (debug 3)))
-    (defstruct foo bar)
-    (let ()
-      (flet ((i (x) (frob x (foo-bar foo))))
-        (i :five)))
-  causes a TYPE-ERROR 
-    The value NIL is not of type SB-C::PHYSENV.
-  in MERGE-LETS.
-
 406: functional has external references -- failed aver
  Given the following food in a single file
   (eval-when (:compile-toplevel :load-toplevel :execute)