0.pre8.16:

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index aace2a0..93d9f25 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -1169,17 +1169,6 @@ WORKAROUND:
 229:
   (subtypep 'function '(function)) => nil, t.
 
-231: "SETQ does not correctly check the type of a variable being set"
-  b.
-    (defun foo (x z)
-      (declare (type integer x))
-      (locally (declare (type (real 1) x))
-        (setq x z))
-      (list x z))
-    (foo 0 0) => (0 0).
-
-  (fixed in 0.7.12.8)
-
 233: bugs in constraint propagation
   a.
   (defun foo (x)
@@ -1203,9 +1192,6 @@ WORKAROUND:
         (+ x 2)))
   (foo 1d0 5) => segmentation violation
 
-234:
-  (fixed in sbcl-0.7.10.36)
-
 235: "type system and inline expansion"
   a.
   (declaim (ftype (function (cons) number) acc))
@@ -1259,6 +1245,40 @@ WORKAROUND:
      calls of the form (TYPEP 1 'INTEGER NIL), even though this is
      just as optimizeable as (TYPEP 1 'INTEGER).
 
+238: "REPL compiler overenthusiasm for CLOS code"
+  From the REPL,
+    * (defclass foo () ())
+    * (defmethod bar ((x foo) (foo foo)) (call-next-method))
+  causes approximately 100 lines of code deletion notes.  Some
+  discussion on this issue happened under the title 'Three "interesting"
+  bugs in PCL', resulting in a fix for this oververbosity from the
+  compiler proper; however, the problem persists in the interactor
+  because the notion of original source is not preserved: for the
+  compiler, the original source of the above expression is (DEFMETHOD
+  BAR ((X FOO) (FOO FOO)) (CALL-NEXT-METHOD)), while by the time the
+  compiler gets its hands on the code needing compilation from the REPL,
+  it has been macroexpanded several times.
+
+241: "DEFCLASS mysteriously remembers uninterned accessor names."
+  (from tonyms on #lisp IRC 2003-02-25)
+  In sbcl-0.7.12.55, typing
+    (defclass foo () ((bar :accessor foo-bar)))
+    (profile foo-bar)
+    (unintern 'foo-bar)
+    (defclass foo () ((bar :accessor foo-bar)))
+  gives the error message
+    "#:FOO-BAR already names an ordinary function or a macro."
+  So it's somehow checking the uninterned old accessor name instead
+  of the new requested accessor name, which seems broken to me (WHN).
+
+242: "WRITE-SEQUENCE suboptimality"
+  (observed from clx performance)
+  In sbcl-0.7.13, WRITE-SEQUENCE of a sequence of type 
+  (SIMPLE-ARRAY (UNSIGNED-BYTE 8) (*)) on a stream with element-type
+  (UNSIGNED-BYTE 8) will write to the stream one byte at a time,
+  rather than writing the sequence in one go, leading to severe
+  performance degradation.
+
 DEFUNCT CATEGORIES OF BUGS
   IR1-#:
     These labels were used for bugs related to the old IR1 interpreter.