0.7.4.21:

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index 0838256..39508d5 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -260,7 +260,6 @@ WORKAROUND:
           MERGE also have the same problem.
        c: (COERCE 'AND 'FUNCTION) returns something related to
           (MACRO-FUNCTION 'AND), but ANSI says it should raise an error.
           MERGE also have the same problem.
        c: (COERCE 'AND 'FUNCTION) returns something related to
           (MACRO-FUNCTION 'AND), but ANSI says it should raise an error.

-       g: (LOAD "*.lsp") should signal FILE-ERROR.

        h: (MAKE-CONCATENATED-STREAM (MAKE-STRING-OUTPUT-STREAM))
           should signal TYPE-ERROR.
        i: MAKE-TWO-WAY-STREAM doesn't check that its arguments can
        h: (MAKE-CONCATENATED-STREAM (MAKE-STRING-OUTPUT-STREAM))
           should signal TYPE-ERROR.
        i: MAKE-TWO-WAY-STREAM doesn't check that its arguments can

@@ -459,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

@@ -488,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.
 

@@ -897,9 +882,6 @@ WORKAROUND:
    Evidently Python thinks of the lambda as a code transformation so
    much that it forgets that it's also an object.
 
    Evidently Python thinks of the lambda as a code transformation so
    much that it forgets that it's also an object.
 

-126:
-  (fixed in 0.pre7.41)
-

 127:
   The DEFSTRUCT section of the ANSI spec, in the :CONC-NAME section,
   specifies a precedence rule for name collisions between slot accessors of
 127:
   The DEFSTRUCT section of the ANSI spec, in the :CONC-NAME section,
   specifies a precedence rule for name collisions between slot accessors of

@@ -1003,36 +985,6 @@ WORKAROUND:
   still some functions named "hairy arg processor" and
   "SB-INT:&MORE processor".
 
   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 is probably due to underzealous clearing of the type caches; a
-  brute-force solution in that case would be to make a defclass expand
-  into something that included a call to SB-KERNEL::CLEAR-TYPE-CACHES,
-  but there may be a better solution.
-

 141: 
   Pretty-printing nested backquotes doesn't work right, as 
   reported by Alexey Dejneka sbcl-devel 2002-01-13:
 141: 
   Pretty-printing nested backquotes doesn't work right, as 
   reported by Alexey Dejneka sbcl-devel 2002-01-13:

@@ -1160,9 +1112,6 @@ WORKAROUND:
   but it has happened in more complicated cases (which I haven't
   figured out how to reproduce).
 
   but it has happened in more complicated cases (which I haven't
   figured out how to reproduce).
 

-155:
-  (fixed in sbcl-0.7.2.9)
-

 156:
   FUNCTION-LAMBDA-EXPRESSION doesn't work right in 0.7.0 or 0.7.2.9:
     * (function-lambda-expression #'(lambda (x) x))
 156:
   FUNCTION-LAMBDA-EXPRESSION doesn't work right in 0.7.0 or 0.7.2.9:
     * (function-lambda-expression #'(lambda (x) x))

@@ -1175,16 +1124,6 @@ WORKAROUND:
   UPGRADED-COMPLEX-PART-TYPE should have an optional environment argument.
   (reported by Alexey Dejneka sbcl-devel 2002-04-12)
 
   UPGRADED-COMPLEX-PART-TYPE should have an optional environment argument.
   (reported by Alexey Dejneka sbcl-devel 2002-04-12)
 

-158:
-  Compiling the following code causes SBCL 0.7.2 to bug. This only
-  happens with optimization enabled, and only when the loop variable is
-  being incremented by more than 1.
-    (defun foo (array)
-      (declare (optimize (safety 0) (space 0) (debug 0) (speed 3)))
-      (loop for i from 0 to 10 by 2
-            do (foo (svref array i))) (svref array (1+ i)))
-  (reported by Eric Marsden sbcl-devel 2002-04-15)
-

 162:
   (reported by Robert E. Brown 2002-04-16) 
   When a function is called with too few arguments, causing the
 162:
   (reported by Robert E. Brown 2002-04-16) 
   When a function is called with too few arguments, causing the

@@ -1205,12 +1144,6 @@ WORKAROUND:
   isn't too surprising since there are many differences in stack
   implementation and GC conservatism between the X86 and other ports.)
 
   isn't too surprising since there are many differences in stack
   implementation and GC conservatism between the X86 and other ports.)
 

-164:
-  The type system still can't quite deal with all useful identities;
-  for instance, as of sbcl-0.7.2.18, the type specifier '(and (real -1
-  7) (real 4 8)) is a HAIRY-TYPE rather than that which would be hoped
-  for, viz: '(real 4 7).
-

 165:
   Array types with element-types of some unknown type are falsely being
   assumed to be of type (ARRAY T) by the compiler in some cases. The
 165:
   Array types with element-types of some unknown type are falsely being
   assumed to be of type (ARRAY T) by the compiler in some cases. The

@@ -1283,39 +1216,49 @@ 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.
-
-170:
-  (reported by Matthias Hoelzl on sbcl-devel 2002-05-13)
-    * (defmacro foo () ''x)
-    FOO
-    * (foo)
-    X
-    * (compile 'foo)
-    FOO
-    NIL
-    NIL
-    * (foo)
-    debugger invoked on condition of type UNDEFINED-FUNCTION:
-      The function FOO is undefined.
-
+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)
+
+175:
+  (fixed in sbcl-0.7.4.14)

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