0.7.13.17:

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index a8ec1da..08fea20 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -1169,6 +1169,17 @@ 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)
@@ -1192,9 +1203,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))
@@ -1248,6 +1256,33 @@ 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).
+
 DEFUNCT CATEGORIES OF BUGS
   IR1-#:
     These labels were used for bugs related to the old IR1 interpreter.