X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=eb00513899f264df950d22578fa4f47fb160cede;hb=179c77c20ae10b7385d6c91a1e6d89842fb690e3;hp=69f27e6aac8b999245b4960ea26d8f1f6e7088dc;hpb=1fdd787fcdac403f92d121701aee8738f710f048;p=sbcl.git

diff --git a/BUGS b/BUGS
index 69f27e6..eb00513 100644
--- a/BUGS
+++ b/BUGS
@@ -458,14 +458,6 @@ WORKAROUND:
   crashes SBCL. In general tracing anything which is used in the 
   implementation of TRACE is likely to have the same problem.
 
-68: 
-  As reported by Daniel Solaz on cmucl-help@cons.org 2000-11-23,
-  SXHASH returns the same value for all non-STRUCTURE-OBJECT instances,
-  notably including all PCL instances. There's a limit to how much
-  SXHASH can do to return unique values for instances, but at least
-  it should probably look at the class name, the way that it does
-  for STRUCTURE-OBJECTs.
-
 70:
   (probably related to bug #65; maybe related to bug #109)
   The compiler doesn't like &OPTIONAL arguments in LABELS and FLET
@@ -487,12 +479,6 @@ WORKAROUND:
                          (SB-C::LAMBDA-TAIL-SET
                           (SB-C::LAMBDA-HOME SB-C::CALLEE))) failed.
 
-71: 
-  (DECLAIM (OPTIMIZE ..)) doesn't work. E.g. even after 
-  (DECLAIM (OPTIMIZE (SPEED 3))), things are still optimized with
-  the previous SPEED policy. This bug will probably get fixed in
-  0.6.9.x in a general cleanup of optimization policy.
-
 72:
   (DECLAIM (OPTIMIZE ..)) doesn't work properly inside LOCALLY forms.
 
@@ -986,18 +972,6 @@ WORKAROUND:
       (let ((x (1+ x)))
         (call-next-method)))
   Now (FOO 3) should return 3, but instead it returns 4.
-    
-137:
-  (SB-DEBUG:BACKTRACE) output should start with something
-  including the name BACKTRACE, not (as in 0.pre7.88)
-  just "0: (\"hairy arg processor\" ...)". Until about
-  sbcl-0.pre7.109, the names in BACKTRACE were all screwed
-  up compared to the nice useful names in sbcl-0.6.13.
-  Around sbcl-0.pre7.109, they were mostly fixed by using
-  NAMED-LAMBDA to implement DEFUN. However, there are still
-  some screwups left, e.g. as of sbcl-0.pre7.109, there are
-  still some functions named "hairy arg processor" and
-  "SB-INT:&MORE processor".
 
 141: 
   Pretty-printing nested backquotes doesn't work right, as 
@@ -1258,6 +1232,120 @@ WORKAROUND:
   code. Since then the warning has been downgraded to STYLE-WARNING, 
   so it's still a bug but at least it's a little less annoying.
 
+174:
+  The error message from attempting to use a #\Return format
+  directive:
+    (format nil "~^M") ; replace "^M" with a literal #\Return
+      debugger invoked on condition of type SB-FORMAT::FORMAT-ERROR:
+      error in format: 		 unknown format directive
+      ~
+       ^
+  is not terribly helpful; this is more noticeable than parallel cases
+  with e.g. #\Backspace because of the differing newline conventions
+  on various operating systems. (reported by Harald Hanche-Olsen on
+  cmucl-help 2002-05-31)
+
+176:
+  reported by Alexey Dejneka 08 Jun 2002 in sbcl-devel:
+    Playing with McCLIM, I've received an error "Unbound variable WRAPPER
+    in SB-PCL::CHECK-WRAPPER-VALIDITY".
+      (defun check-wrapper-validity (instance)
+        (let* ((owrapper (wrapper-of instance)))
+          (if (not (invalid-wrapper-p owrapper))
+              owrapper
+              (let* ((state (wrapper-state wrapper)) ; !!!
+        ...
+    I've tried to replace it with OWRAPPER, but now OBSOLETE-INSTANCE-TRAP
+    breaks with "NIL is not of type SB-KERNEL:LAYOUT".
+    SBCL 0.7.4.13.
+  partial fix: The undefined variable WRAPPER resulted from an error
+  in recent refactoring, as can be seen by comparing to the code in e.g. 
+  sbcl-0.7.2. Replacing WRAPPER with OWRAPPER (done by WHN in sbcl-0.7.4.22)
+  should bring the code back to its behavior as of sbcl-0.7.2, but
+  that still leaves the OBSOLETE-INSTANCE-TRAP bug. An example of 
+  input which triggers that bug is
+    (dotimes (i 20)
+      (let ((lastname (intern (format nil "C~D" (1- i))))
+            (name (intern (format nil "C~D" i))))
+      (eval `(defclass ,name
+                 (,@(if (= i 0) nil (list lastname)))
+               ()))
+      (eval `(defmethod initialize-instance :after ((x ,name) &rest any)
+               (declare (ignore any))))))
+    (defclass b () ())
+    (defclass c0 (b) ())
+    (make-instance 'c19)
+
+178: "AVER failure compiling confused THEs in FUNCALL"
+  In sbcl-0.7.4.24, compiling
+    (defun bug178 (x)
+      (funcall (the function (the standard-object x))))
+  gives 
+    failed AVER:
+      "(AND (EQ (IR2-CONTINUATION-PRIMITIVE-TYPE 2CONT) FUNCTION-PTYPE) (EQ CHECK T))"
+  This variant compiles OK, though:
+    (defun bug178alternative (x)
+      (funcall (the nil x)))
+
+179:
+  (fixed in sbcl-0.7.4.28)
+
+180:
+  In sbcl-0.7.4.35, PCL seems not to understand the :MOST-SPECIFIC-LAST
+  option for PROGN method combination. It does understand that
+  :MOST-SPECIFIC-FIRST and :MOST-SPECIFIC-LAST belong with PROGN.
+  If I use another keyword, it complains:
+    (defgeneric foo ((x t))
+      (:method-combination progn :most-specific-first))
+  outputs
+    method combination error in CLOS dispatch:
+    Illegal options to a short method combination type.
+    The method combination type PROGN accepts one option which
+    must be either :MOST-SPECIFIC-FIRST or :MOST-SPECIFIC-LAST.
+  And when I use :MOST-SPECIFIC-FIRST, I get the expected default
+  behavior:
+    (defgeneric foo ((x t))
+      (:method-combination progn :most-specific-first))
+    (defmethod foo progn ((x number))
+      (print 'number))
+    (defmethod foo progn ((x fixnum))
+      (print 'fixnum))
+    (foo 14)
+  outputs
+    FIXNUM 
+    NUMBER 
+  and returns
+    NUMBER
+  But with :MOST-SPECIFIC-LAST,
+    (defgeneric foo ((x t))
+      (:method-combination progn :most-specific-last))
+    (defmethod foo progn ((x number))
+      (print 'number))
+    (defmethod foo progn ((x fixnum))
+      (print 'fixnum))
+    (foo 14)
+  the behavior doesn't change, giving output of
+    FIXNUM 
+    NUMBER 
+  and returning
+    NUMBER
+  Raymond Toy reported 2002-06-15 on sbcl-devel that CMU CL's PCL
+  doesn't seem to have this bug, outputting NUMBER before FIXNUM
+  as expected in the last case above.
+
+181:
+  Compiling 
+    (in-package :cl-user)
+    (defun bar (x)
+      (declare (type 0 x))
+      (cons x x))
+  signals 
+    bad thing to be a type specifier: 0
+  which seems fine, but also enters the debugger (instead of having
+  the compiler handle the error, convert it into a COMPILER-ERROR, and
+  continue compiling) which seems wrong.
+
+  
 DEFUNCT CATEGORIES OF BUGS
   IR1-#:
     These labels were used for bugs related to the old IR1 interpreter.