0.7.4.40:

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index ad7b82a..bba6c83 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,36 @@ 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".
+
+140:
+  (reported by Alexey Dejneka sbcl-devel 2002-01-03)
+
+  SUBTYPEP does not work well with redefined classes:
+  ---
+  * (defclass a () ())
+  #<STANDARD-CLASS A>
+  * (defclass b () ())
+  #<STANDARD-CLASS B>
+  * (subtypep 'b 'a)
+  NIL
+  T
+  * (defclass b (a) ())
+  #<STANDARD-CLASS B>
+  * (subtypep 'b 'a)
+  T
+  T
+  * (defclass b () ())
+  #<STANDARD-CLASS B>
+   
+  ;;; And now...
+  * (subtypep 'b 'a)
+  T
+  T
+
+  This bug was fixed in sbcl-0.7.4.1 by invalidating the PCL wrapper
+  class upon redefinition. Unfortunately, doing so causes bug #176 to
+  appear.  Pending further investication, one or other of these bugs
+  might be present at any given time.

 
 141: 
   Pretty-printing nested backquotes doesn't work right, as 
 
 141: 
   Pretty-printing nested backquotes doesn't work right, as 

@@ -1230,30 +1234,134 @@ WORKAROUND:
   Since this is a reasonable user error, it shouldn't be reported as 
   an SBCL bug. 
 
   Since this is a reasonable user error, it shouldn't be reported as 
   an SBCL bug. 
 

-169:
-  (reported by Alexey Dejneka on sbcl-devel 2002-05-12)
-  * (defun test (n)
-      (let ((*x* n))
-        (declare (special *x*))
-        (getx)))
-  ; in: LAMBDA NIL
-  ;     (LET ((*X* N))
-  ;     (DECLARE (SPECIAL *X*))
-  ;     (GETX))
-  ;
-  ; caught STYLE-WARNING:
-  ;   using the lexical binding of the symbol *X*, not the
-  ; dynamic binding, even though the symbol name follows the usual naming
-  ; convention (names like *FOO*) for special variables
-  ; compilation unit finished
-  ;   caught 1 STYLE-WARNING condition
-  But the code works as it should. Checked in 0.6.12.43 and later.
-

 171:
   (reported by Pierre Mai while investigating bug 47):
     (DEFCLASS FOO () ((A :SILLY T))) 
   signals a SIMPLE-ERROR, not a PROGRAM-ERROR.
 
 171:
   (reported by Pierre Mai while investigating bug 47):
     (DEFCLASS FOO () ((A :SILLY T))) 
   signals a SIMPLE-ERROR, not a PROGRAM-ERROR.
 

+172:
+  sbcl's treatment of at least macro lambda lists is too permissive;
+  e.g., in sbcl-0.7.3.7:
+    (defmacro foo (&rest rest bar) `(,bar ,rest))
+    (macroexpand '(foo quux zot)) -> (QUUX (QUUX ZOT))
+  whereas section 3.4.4 of the CLHS doesn't allow required parameters
+  to come after the rest argument.
+
+173:
+  The compiler sometimes tries to constant-fold expressions before
+  it checks to see whether they can be reached. This can lead to 
+  bogus warnings about errors in the constant folding, e.g. in code
+  like 
+    (WHEN X
+      (WRITE-STRING (> X 0) "+" "0"))
+  compiled in a context where the compiler can prove that X is NIL,
+  and the compiler complains that (> X 0) causes a type error because
+  NIL isn't a valid argument to #'>. Until sbcl-0.7.4.10 or so this
+  caused a full WARNING, which made the bug really annoying because then 
+  COMPILE and COMPILE-FILE returned FAILURE-P=T for perfectly legal
+  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)
+
+  See also bug #140.
+
+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)))
+
+181: "bad type specifier drops compiler into debugger"
+  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.
+
+182: "SPARC/Linux floating point"
+  Evaluating (/ 1.0 0.0) at the prompt causes a Bus error and complete
+  death of the environment. Other floating point operations sometimes
+  return infinities when they should raise traps (e.g. the test case
+  for bug #146, (expt 2.0 12777)).
+
+183: "IEEE floating point issues"
+  Even where floating point handling is being dealt with relatively
+  well (as of sbcl-0.7.5, on sparc/sunos and alpha; see bug #146), the
+  accrued-exceptions and current-exceptions part of the fp control
+  word don't seem to bear much relation to reality. E.g. on
+  SPARC/SunOS:
+  * (/ 1.0 0.0)
+
+  debugger invoked on condition of type DIVISION-BY-ZERO:
+    arithmetic error DIVISION-BY-ZERO signalled
+  0] (sb-vm::get-floating-point-modes)
+
+  (:TRAPS (:OVERFLOW :INVALID :DIVIDE-BY-ZERO)
+          :ROUNDING-MODE :NEAREST
+          :CURRENT-EXCEPTIONS NIL
+          :ACCRUED-EXCEPTIONS (:INEXACT)
+          :FAST-MODE NIL)
+  0] abort
+  * (sb-vm::get-floating-point-modes)
+  (:TRAPS (:OVERFLOW :INVALID :DIVIDE-BY-ZERO)
+          :ROUNDING-MODE :NEAREST
+          :CURRENT-EXCEPTIONS (:INEXACT)
+          :ACCRUED-EXCEPTIONS (:INEXACT)
+          :FAST-MODE NIL)
+

 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.