X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=4e6b5db06e6c4e207254fdd32fd96af10bf8e66f;hb=0520c59af85dca3ddf8c06303b44a0943c83b451;hp=f4f846441ba88f4039d55630cd3b454cefd28c0a;hpb=c5c178ceac9f34b2c3580557fec1ffe15073ac99;p=sbcl.git

diff --git a/BUGS b/BUGS
index f4f8464..4e6b5db 100644
--- a/BUGS
+++ b/BUGS
@@ -626,7 +626,6 @@ WORKAROUND:
 
   (note the space between the comma and the point)
 
-
 143:
   (reported by Jesse Bouwman 2001-10-24 through the unfortunately
   prominent SourceForge web/db bug tracking system, which is 
@@ -717,11 +716,6 @@ WORKAROUND:
   expansion, leaving garbage consisting of infinished blocks of the
   partially converted function.)
 
-157:
-  Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and 
-  UPGRADED-COMPLEX-PART-TYPE should have an optional environment argument.
-  (reported by Alexey Dejneka sbcl-devel 2002-04-12)
-
 162:
   (reported by Robert E. Brown 2002-04-16) 
   When a function is called with too few arguments, causing the
@@ -1172,15 +1166,6 @@ WORKAROUND:
   would be to put the check between evaluation of arguments, but it
   could be tricky to check result types of PROG1, IF etc.
 
-228: "function-lambda-expression problems"
-  in sbcl-0.7.9.6x, from the REPL:
-    * (progn (declaim (inline foo)) (defun foo (x) x))
-    FOO
-    * (function-lambda-expression #'foo)
-    (SB-C:LAMBDA-WITH-LEXENV NIL NIL NIL (X) (BLOCK FOO X)), NIL, FOO
-  but this first return value is not suitable for input to FUNCTION or
-  COMPILE, as required by ANSI.
-
 229:
   (subtypep 'function '(function)) => nil, t.
 
@@ -1197,6 +1182,7 @@ WORKAROUND:
   (foo 4) => segmentation violation
 
   (see usage of CONTINUATION-ASSERTED-TYPE in USE-RESULT-CONSTRAINTS)
+  (see also bug 236)
 
   b.
   (declaim (optimize (speed 2) (safety 3)))
@@ -1206,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))
@@ -1235,6 +1218,59 @@ WORKAROUND:
   Without (DECLARE (NOTINLINE MAPCAR)), Python cannot derive that Z is
   LIST.
 
+236: "THE semantics is broken"
+
+  (defun foo (a f)
+    (declare (optimize (speed 2) (safety 0)))
+    (+ 1d0
+       (the double-float
+         (multiple-value-prog1
+             (svref a 0)
+           (unless f (return-from foo 0))))))
+
+  (foo #(4) nil) => SEGV
+
+  VOP selection thinks that in unsafe code result type assertions
+  should be valid immediately. (See also bug 233a.)
+
+  The similar problem exists for TRULY-THE.
+
+237: "Environment arguments to type functions"
+  a. Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and 
+     UPGRADED-COMPLEX-PART-TYPE now have an optional environment
+     argument, but they ignore it completely.  This is almost 
+     certainly not correct.
+  b. Also, the compiler's optimizers for TYPEP have not been informed
+     about the new argument; consequently, they will not transform
+     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.