0.7.7.40:

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index ffc5ebb..b7c3b53 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -1,4 +1,4 @@
-tREPORTING BUGS
+REPORTING BUGS

 
 Bugs can be reported on the help mailing list
   sbcl-help@lists.sourceforge.net
 
 Bugs can be reported on the help mailing list
   sbcl-help@lists.sourceforge.net

@@ -183,7 +183,8 @@ WORKAROUND:
   then executing
     (FOO 1.5)
   will cause the INTEGERP case to be selected, giving bogus output a la
   then executing
     (FOO 1.5)
   will cause the INTEGERP case to be selected, giving bogus output a la

-    exactly 1.33..
+    exactly 2.5
+  (or (FOO 1000.5), "exactly 1001.5")

   This violates the "declarations are assertions" principle.
   According to the ANSI spec, in the section "System Class FUNCTION",
   this is a case of "lying to the compiler", but the lying is done
   This violates the "declarations are assertions" principle.
   According to the ANSI spec, in the section "System Class FUNCTION",
   this is a case of "lying to the compiler", but the lying is done

@@ -276,13 +277,6 @@ WORKAROUND:
 
 47:
   DEFCLASS bugs reported by Peter Van Eynde July 25, 2000:
 
 47:
   DEFCLASS bugs reported by Peter Van Eynde July 25, 2000:

-       a: (DEFCLASS FOO () (A B A)) should signal a PROGRAM-ERROR, and
-          doesn't.
-       b: (DEFCLASS FOO () (A B A) (:DEFAULT-INITARGS X A X B)) should
-          signal a PROGRAM-ERROR, and doesn't.
-       c: (DEFCLASS FOO07 NIL ((A :ALLOCATION :CLASS :ALLOCATION :CLASS))),
-          and other DEFCLASS forms with duplicate specifications in their
-          slots, should signal a PROGRAM-ERROR, and doesn't.

        d: (DEFGENERIC IF (X)) should signal a PROGRAM-ERROR, but instead
           causes a COMPILER-ERROR.
 
        d: (DEFGENERIC IF (X)) should signal a PROGRAM-ERROR, but instead
           causes a COMPILER-ERROR.
 

@@ -303,9 +297,6 @@ WORKAROUND:
              (DEFGENERIC FOO03 (X))
              (ADD-METHOD (FUNCTION FOO03) M)))
           should give an error, but SBCL allows it.
              (DEFGENERIC FOO03 (X))
              (ADD-METHOD (FUNCTION FOO03) M)))
           should give an error, but SBCL allows it.

-       b: READ should probably return READER-ERROR, not the bare 
-          arithmetic error, when input a la "1/0" or "1e1000" causes
-          an arithmetic error.

 
 52:
   It has been reported (e.g. by Peter Van Eynde) that there are 
 
 52:
   It has been reported (e.g. by Peter Van Eynde) that there are 

@@ -582,25 +573,6 @@ WORKAROUND:
   type declarations are supposed to be treated as assertions unless
   SAFETY 0, so we should be getting a TYPE-ERROR.
 
   type declarations are supposed to be treated as assertions unless
   SAFETY 0, so we should be getting a TYPE-ERROR.
 

-113:
-  reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
-  collection:
-    (in-package :cl-user)
-    ;;; From: David Gadbois <gadbois@cyc.com>
-    ;;;
-    ;;; Logical pathnames aren't externalizable.
-    ;;; Test case:
-    (let ((tempfile "/tmp/test.lisp"))
-      (setf (logical-pathname-translations "XXX")
-            '(("XXX:**;*.*" "/tmp/**/*.*")))
-      (with-open-file (out tempfile :direction :output)
-        (write-string "(defvar *path* #P\"XXX:XXX;FOO.LISP\")" out))
-      (compile-file tempfile))
-  The error message in sbcl-0.6.12.42 is
-    ; caught ERROR:
-    ;   (while making load form for #<SB-IMPL::LOGICAL-HOST "XXX">)
-    ; A logical host can't be dumped as a constant: #<SB-IMPL::LOGICAL-HOST "XXX">
-

 115:
   reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
   collection:
 115:
   reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
   collection:

@@ -672,7 +644,9 @@ WORKAROUND:
    (IF (NOT (IGNORE-ERRORS ..))). E.g.
        (defun foo1i ()
          (if (not (ignore-errors
    (IF (NOT (IGNORE-ERRORS ..))). E.g.
        (defun foo1i ()
          (if (not (ignore-errors

-                    (make-pathname :host "foo" :directory "!bla" :name "bar")))
+                    (make-pathname :host "foo"
+                                    :directory "!bla"
+                                    :name "bar")))

              (print "ok")
              (error "notunlessnot")))
    The (NOT (IGNORE-ERRORS ..)) form evaluates to T, so this should be
              (print "ok")
              (error "notunlessnot")))
    The (NOT (IGNORE-ERRORS ..)) form evaluates to T, so this should be

@@ -756,65 +730,6 @@ WORKAROUND:
        (bar x)))
   shouldn't compile without error (because of the extra DEFMACRO symbol).
 
        (bar x)))
   shouldn't compile without error (because of the extra DEFMACRO symbol).
 

-131:
-  As of sbcl-0.pre7.86.flaky7.3, the cross-compiler, and probably 
-  the CL:COMPILE function (which is based on the same %COMPILE 
-  mechanism) get confused by 
-(defun sxhash (x)
-  (labels ((sxhash-number (x)
-            (etypecase x
-              (fixnum (sxhash x)) ; through DEFTRANSFORM
-              (integer (sb!bignum:sxhash-bignum x))
-              (single-float (sxhash x)) ; through DEFTRANSFORM
-              (double-float (sxhash x)) ; through DEFTRANSFORM
-              #!+long-float (long-float (error "stub: no LONG-FLOAT"))
-              (ratio (let ((result 127810327))
-                       (declare (type fixnum result))
-                       (mixf result (sxhash-number (numerator x)))
-                       (mixf result (sxhash-number (denominator x)))
-                       result))
-              (complex (let ((result 535698211))
-                         (declare (type fixnum result))
-                         (mixf result (sxhash-number (realpart x)))
-                         (mixf result (sxhash-number (imagpart x)))
-                         result))))
-          (sxhash-recurse (x &optional (depthoid +max-hash-depthoid+))
-            (declare (type index depthoid))
-            (typecase x
-              (list
-               (if (plusp depthoid)
-                   (mix (sxhash-recurse (car x) (1- depthoid))
-                        (sxhash-recurse (cdr x) (1- depthoid)))
-                   261835505))
-              (instance
-               (if (typep x 'structure-object)
-                   (logxor 422371266
-                           (sxhash ; through DEFTRANSFORM
-                            (class-name (layout-class (%instance-layout x)))))
-                   309518995))
-              (symbol (sxhash x)) ; through DEFTRANSFORM
-              (number (sxhash-number x))
-              (array
-               (typecase x
-                 (simple-string (sxhash x)) ; through DEFTRANSFORM
-                 (string (%sxhash-substring x))
-                 (bit-vector (let ((result 410823708))
-                               (declare (type fixnum result))
-                               (dotimes (i (min depthoid (length x)))
-                                 (mixf result (aref x i)))
-                               result))
-                 (t (logxor 191020317 (sxhash (array-rank x))))))
-              (character
-               (logxor 72185131
-                       (sxhash (char-code x)))) ; through DEFTRANSFORM
-              (t 42))))
-    (sxhash-recurse x)))
-  complaining "function called with two arguments, but wants exactly
-  one" about SXHASH-RECURSE. (This might not be strictly a new bug, 
-  since IIRC post-fork CMU CL has also had problems with &OPTIONAL
-  arguments in FLET/LABELS: it might be an old Python bug which is 
-  only exercised by the new arrangement of the SBCL compiler.)
-

 135:
   Ideally, uninterning a symbol would allow it, and its associated
   FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However, 
 135:
   Ideally, uninterning a symbol would allow it, and its associated
   FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However, 

@@ -1045,23 +960,6 @@ WORKAROUND:
   macro is unhappy with the illegal syntax in the method body, and
   is giving an unclear error message.
 
   macro is unhappy with the illegal syntax in the method body, and
   is giving an unclear error message.
 

-168:
-  (reported by Dan Barlow on sbcl-devel 2002-05-10)
-  In sbcl-0.7.3.12, doing
-    (defstruct foo bar baz)
-    (compile nil (lambda (x) (or x (foo-baz x))))
-  gives an error
-    debugger invoked on condition of type SB-INT:BUG:
-       full call to SB-KERNEL:%INSTANCE-REF
-    This is probably a bug in SBCL itself. [...]
-  Since this is a reasonable user error, it shouldn't be reported as 
-  an SBCL bug. 
-
-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:
 172:
   sbcl's treatment of at least macro lambda lists is too permissive;
   e.g., in sbcl-0.7.3.7:

@@ -1085,19 +983,6 @@ 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
 176:
   reported by Alexey Dejneka 08 Jun 2002 in sbcl-devel:
     Playing with McCLIM, I've received an error "Unbound variable WRAPPER

@@ -1142,18 +1027,6 @@ WORKAROUND:
     (defun bug178alternative (x)
       (funcall (the nil x)))
 
     (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.
-

 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
 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

@@ -1310,17 +1183,9 @@ WORKAROUND:
      lists and &KEY arguments) do not signal errors when they should.
 
 192: "Python treats free type declarations as promises."
      lists and &KEY arguments) do not signal errors when they should.
 
 192: "Python treats free type declarations as promises."

-  a. original report by Alexey Dejneka (on sbcl-devel 2002-08-26):
-       (declaim (optimize (speed 0) (safety 3)))
-       (defun f (x)
-         (declare (real x))
-         (+ x
-            (locally (declare (single-float x))
-            (sin x))))
-     Now (F NIL) correctly gives a type error, but (F 100) gives
-     a segmentation violation.
-  b. same fundamental problem in a different way, easy to stumble
-     across if you mistype and declare the wrong index in
+  b. What seemed like the same fundamental problem as bug 192a, but
+     was not fixed by the same (APD "more strict type checking
+     sbcl-devel 2002-08-97) patch:

      (DOTIMES (I ...) (DOTIMES (J ...) (DECLARE ...) ...)):
        (declaim (optimize (speed 1) (safety 3)))
        (defun trust-assertion (i)
      (DOTIMES (I ...) (DOTIMES (J ...) (DECLARE ...) ...)):
        (declaim (optimize (speed 1) (safety 3)))
        (defun trust-assertion (i)

@@ -1349,6 +1214,97 @@ WORKAROUND:
   error message stays the same (even BACKTRACE doesn't tell you what the
   bad argument value is).
 
   error message stays the same (even BACKTRACE doesn't tell you what the
   bad argument value is).
 

+194: "no error from (THE REAL '(1 2 3)) in some cases"
+  fixed parts:
+    a. In sbcl-0.7.7.9, 
+         (multiple-value-prog1 (progn (the real '(1 2 3))))
+       returns (1 2 3) instead of signalling an error. This was fixed by 
+       APD's "more strict type checking patch", but although the fixed
+       code (in sbcl-0.7.7.19) works (signals TYPE-ERROR) interactively,
+       it's difficult to write a regression test for it, because 
+       (IGNORE-ERRORS (MULTIPLE-VALUE-PROG1 (PROGN (THE REAL '(1 2 3)))))
+       still returns (1 2 3).
+  still-broken parts:  
+    b. (IGNORE-ERRORS (MULTIPLE-VALUE-PROG1 (PROGN (THE REAL '(1 2 3)))))    
+       returns (1 2 3). (As above, this shows up when writing regression
+       tests for fixed-ness of part a.)
+    c. Also in sbcl-0.7.7.9, (IGNORE-ERRORS (THE REAL '(1 2 3))) => (1 2 3).
+    d. At the REPL,
+         (null (ignore-errors
+           (let ((arg1 1)
+                 (arg2 (identity (the real #(1 2 3)))))
+             (if (< arg1 arg2) arg1 arg2))))
+           => T
+      but putting the same expression inside (DEFUN FOO () ...),
+      (FOO) => NIL.
+  notes:
+    * Actually this entry is probably multiple bugs, as
+      Alexey Dejneka commented on sbcl-devel 2002-09-03:)
+       I don't think that placing these two bugs in one entry is
+       a good idea: they have different explanations. The second
+       (min 1 nil) is caused by flushing of unused code--IDENTITY
+       can do nothing with it. So it is really bug 122. The first
+       (min nil) is due to M-V-PROG1: substituting a continuation
+       for the result, it forgets about type assertion. The purpose
+       of IDENTITY is to save the restricted continuation from
+       inaccurate transformations.
+    * Alexey Dejneka pointed out that
+       (IGNORE-ERRORS (IDENTITY (THE REAL '(1 2 3))))
+      works as it should. Also
+       (IGNORE-ERRORS (VALUES (THE REAL '(1 2 3))))
+      works as it should. Perhaps this is another case of VALUES type
+      intersections behaving in non-useful ways?
+
+199: "hairy FUNCTION types confuse the compiler"
+  (reported by APD sbcl-devel 2002-09-15)
+    (DEFUN MUR (F)
+      (EQ NIL (FUNCALL F)))
+
+    (DEFUN FOO (F X)
+      (DECLARE (TYPE (AND FUNCTION (SATISFIES MUR)) F))
+      (FUNCALL F X))
+
+  fails to compile, printing
+    failed AVER:
+      "(AND (EQ (IR2-CONTINUATION-PRIMITIVE-TYPE 2CONT) FUNCTION-PTYPE) (EQ CHECK T))"
+
+  APD further reports that this bug is not present in CMUCL.
+
+201: "Incautious type inference from compound CONS types"
+  (reported by APD sbcl-devel 2002-09-17)
+    (DEFUN FOO (X)
+      (LET ((Y (CAR (THE (CONS INTEGER *) X))))
+        (SETF (CAR X) NIL)
+        (FORMAT NIL "~S IS ~S, Y = ~S"
+                (CAR X)
+                (TYPECASE (CAR X)
+                  (INTEGER 'INTEGER)
+                  (T '(NOT INTEGER)))
+                Y)))
+
+    (FOO ' (1 . 2)) => "NIL IS INTEGER, Y = 1"
+
+202:
+  In 0.6.12.43 compilation of a function definition, contradicting its
+  FTYPE proclamation, causes an error, e.g. COMPILE-FILE on
+
+    (declaim (ftype (function () null) foo))
+    (defun foo () t)
+
+  fails with
+
+    debugger invoked on condition of type UNBOUND-VARIABLE:
+    The variable SB-C::*ERROR-FUNCTION* is unbound.
+
+  in
+
+    (SB-C::NOTE-LOSSAGE
+       "~@<The previously declared FTYPE~2I ~_~S~I ~_~
+                              conflicts with the definition type ~2I~_~S~:>"
+       (FUNCTION NIL NULL)
+       (FUNCTION NIL #))
+
+  (In 0.7.0 the variable was renamed to SB-C::*LOSSAGE-FUN*.)

 
 DEFUNCT CATEGORIES OF BUGS
   IR1-#:
 
 DEFUNCT CATEGORIES OF BUGS
   IR1-#: