0.7.13.4:

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index a8ec1da..1b6c039 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)
@@ -1248,6 +1259,49 @@ 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.
+
+240:
+  "confused lexical/special warnings in MULTIPLE-VALUE-BIND"
+  (from tonyms on #lisp IRC 2003-02-25)
+  In sbcl-0.7.12.55, compiling 
+    (cl:in-package :cl-user)
+    (defvar *foo* 0)
+    (defvar *bar* 1)
+    (defun bar ()
+      (multiple-value-bind (*foo* *bar*) 'eleventy-one
+        (bletch)))
+    (defun bletch () (format t "~&*FOO*=~S *BAR*=~S" *foo* *bar*))
+    (bar)
+  gives warnings like "using the lexical binding of the symbol *FOO*"
+  even though LOADing the fasl file shows that in fact the special
+  bindings are being used.
+
+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.