0.7.4.36:

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index 69f27e6..eb00513 100644 (file)
--- 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.
 
   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
 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.
 
                          (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.
 
 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.
       (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 
 
 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.
 
   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.
 DEFUNCT CATEGORIES OF BUGS
   IR1-#:
     These labels were used for bugs related to the old IR1 interpreter.