X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=36986f94e738a37d4fb4e03fbb140c445ec0ae28;hb=6c4d4d984b1af6b2a73568cec3ab9c8795cff2da;hp=7942a1f0619d48015b8343c1567bef4210695759;hpb=1234f4cd25b2d50dfa2645d66757116e64b7aae2;p=sbcl.git

diff --git a/BUGS b/BUGS
index 7942a1f..36986f9 100644
--- a/BUGS
+++ b/BUGS
@@ -1263,14 +1263,123 @@ WORKAROUND:
   to see that it should cause symbols to be interned in the CL package.)
 
 209: "DOCUMENTATION generic function has wrong argument precedence order"
-  The method from 
-    (DEFMETHOD DOCUMENTATION ((X (EQL '+)) Y) "WRONG!")
-  should not be executed in the call 
-    (DOCUMENTATION '+ 'FUNCTION),
-  as the DOCUMENTATION generic function has a different argument
-  precedence order (see its entry in the CLHS). However, despite a
-  correct generic function definition in the PCL source code, SBCL
-  returns "WRONG!" for the call.
+  (fixed in sbcl-0.7.8.39)
+
+210: "unsafe evaluation of DEFSTRUCT slot initforms in BOA constructors"
+  (fixed in sbcl-0.7.8.35)
+
+211: "keywords processing"
+  a. :ALLOW-OTHER-KEYS T should allow a function to receive an odd
+     number of keyword arguments.
+  e. Compiling
+
+      (flet ((foo (&key y) (list y)))
+        (list (foo :y 1 :y 2)))
+
+     issues confusing message
+
+       ; in: LAMBDA NIL
+       ;     (FOO :Y 1 :Y 2)
+       ; 
+       ; caught STYLE-WARNING:
+       ;   The variable #:G15 is defined but never used.
+
+
+212: "Sequence functions and circular arguments"
+  COERCE, MERGE and CONCATENATE go into an infinite loop when given
+  circular arguments; it would be good for the user if they could be
+  given an error instead (ANSI 17.1.1 allows this behaviour on the part
+  of the implementation, as conforming code cannot give non-proper
+  sequences to these functions.  MAP also has this problem (and
+  solution), though arguably the convenience of being able to do 
+    (MAP 'LIST '+ FOO '#1=(1 . #1#)) 
+  might be classed as more important (though signalling an error when
+  all of the arguments are circular is probably desireable).
+
+213: "Sequence functions and type checking"
+  a. MAKE-SEQUENCE, COERCE, MERGE and CONCATENATE cannot deal with
+     various complicated, though recognizeable, CONS types [e.g. 
+       (CONS * (CONS * NULL))
+     which according to ANSI should be recognized] (and, in SAFETY 3
+     code, should return a list of LENGTH 2 or signal an error)
+  b. MAP, when given a type argument that is SUBTYPEP LIST, does not
+     check that it will return a sequence of the given type.  Fixing
+     it along the same lines as the others (cf. work done around
+     sbcl-0.7.8.45) is possible, but doing so efficiently didn't look
+     entirely straightforward.
+  c. All of these functions will silently accept a type of the form
+       (CONS INTEGER *)
+     whether or not the return value is of this type.  This is
+     probably permitted by ANSI (see "Exceptional Situations" under
+     ANSI MAKE-SEQUENCE), but the DERIVE-TYPE mechanism does not 
+     know about this escape clause, so code of the form
+       (INTEGERP (CAR (MAKE-SEQUENCE '(CONS INTEGER *) 2)))
+     can erroneously return T.
+
+214:
+  SBCL 0.6.12.43 fails to compile
+
+  (locally
+      (declare (optimize (inhibit-warnings 0) (compilation-speed 2)))
+    (flet ((foo (&key (x :vx x-p)) (list x x-p)))
+      (foo 1 2)))
+
+  or a more simple example:
+
+  (locally
+      (declare (optimize (inhibit-warnings 0) (compilation-speed 2)))
+    (lambda (x) (declare (fixnum x)) (if (< x 0) 0 (1- x))))
+
+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.
+
+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
+  leaves the system confused, enough so that (QUIT) no longer works.
+  It's as though the process of working with the uninitialized slot in
+  the bad VECTOR-PUSH-EXTEND frame causes GC problems, though that may
+  not be the actual problem. (CMU CL 18c doesn't have problems with this.)
+
+217: "Bad type operations with FUNCTION types"
+  In sbcl.0.7.7:
+
+    * (values-type-union (specifier-type '(function (base-char)))
+                         (specifier-type '(function (integer))))
+
+    #<FUN-TYPE (FUNCTION (BASE-CHAR) *)>
+
+  It causes insertion of wrong type assertions into generated
+  code. E.g.
+
+    (defun foo (x s)
+      (let ((f (etypecase x
+                 (character #'write-char)
+                 (integer #'write-byte))))
+        (funcall f x s)
+        (etypecase x
+          (character (write-char x s))
+          (integer (write-byte x s)))))
+
+   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.)
+
 
 DEFUNCT CATEGORIES OF BUGS
   IR1-#: