0.7.7.20-backend-cleanup-1.5:

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index a2af047..60c6505 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.
 

@@ -582,25 +576,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 +647,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

@@ -1057,11 +1034,6 @@ 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. 
 

-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 +1057,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

@@ -1310,17 +1269,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)

@@ -1350,13 +1301,57 @@ WORKAROUND:
   bad argument value is).
 
 194: "no error from (THE REAL '(1 2 3)) in some cases"
   bad argument value is).
 
 194: "no error from (THE REAL '(1 2 3)) in some cases"

-  In sbcl-0.7.7.9, 
-    (multiple-value-prog1 (progn (the real '(1 2 3))))
-  returns (1 2 3) instead of signalling an error. Also in sbcl-0.7.7.9,
-  a more complicated instance of this bug kept 
-  (IGNORE-ERRORS (MIN '(1 2 3))) from returning NIL as it should when
-  the MIN source transform expanded to (THE REAL '(1 2 3)), because
-  (IGNORE-ERRORS (THE REAL '(1 2 3))) returns (1 2 3).
+  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?
+
+195: "confusing reporting of not-a-REAL TYPE-ERRORs from THE REAL"
+  In sbcl-0.7.7.10, (THE REAL #(1 2 3)) signals a type error which
+  prints as "This is not a (OR SINGLE-FLOAT DOUBLE-FLOAT RATIONAL)".
+  The (OR SINGLE-FLOAT DOUBLE-FLOAT RATIONAL) representation of
+  REAL is unnecessarily confusing, especially since it relies on 
+  internal implementation knowledge that even with SHORT-FLOAT
+  and LONG-FLOAT left out of the union, this type is equal to REAL.
+  So it'd be better just to say "This is not a REAL".
+
+196: "confusing error message for unREAL second arg to ATAN"
+  (fixed in sbcl-0.7.7.18)

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