0.7.4.7:

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index 4286531..409cdf8 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -142,15 +142,6 @@ WORKAROUND:
   DTC's recommended workaround from the mailing list 3 Mar 2000:
        (setf (pcl::find-class 'ccc1) (pcl::find-class 'ccc))
 
   DTC's recommended workaround from the mailing list 3 Mar 2000:
        (setf (pcl::find-class 'ccc1) (pcl::find-class 'ccc))
 

-22:
-  The ANSI spec, in section "22.3.5.2 Tilde Less-Than-Sign: Logical Block",
-  says that an error is signalled if ~W, ~_, ~<...~:>, ~I, or ~:T is used
-  inside "~<..~>" (without the colon modifier on the closing syntax).
-  However, SBCL doesn't do this:
-       * (FORMAT T "~<munge~wegnum~>" 12)
-       munge12egnum
-       NIL
-

 27:
   Sometimes (SB-EXT:QUIT) fails with 
        Argh! maximum interrupt nesting depth (4096) exceeded, exiting
 27:
   Sometimes (SB-EXT:QUIT) fails with 
        Argh! maximum interrupt nesting depth (4096) exceeded, exiting

@@ -269,9 +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.

-       f: (FLOAT-RADIX 2/3) should signal an error instead of 
-          returning 2.
-       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

@@ -279,10 +267,6 @@ WORKAROUND:
           TYPE-ERROR when handed e.g. the results of
           MAKE-STRING-INPUT-STREAM or MAKE-STRING-OUTPUT-STREAM in
           the inappropriate positions, but doesn't.
           TYPE-ERROR when handed e.g. the results of
           MAKE-STRING-INPUT-STREAM or MAKE-STRING-OUTPUT-STREAM in
           the inappropriate positions, but doesn't.

-       j: (PARSE-NAMESTRING (COERCE (LIST #\f #\o #\o (CODE-CHAR 0) #\4 #\8)
-                           (QUOTE STRING)))
-          should probably signal an error instead of making a pathname with
-          a null byte in it.

        k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is 
           not a binary input stream, but instead cheerfully reads from
           character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc").
        k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is 
           not a binary input stream, but instead cheerfully reads from
           character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc").

@@ -667,7 +651,7 @@ WORKAROUND:
   but SBCL doesn't do this. (Also as reported by AL in the same
   message, SBCL depended on this nonconforming behavior to build
   itself, because of the way that **CURRENT-SEGMENT** was implemented.
   but SBCL doesn't do this. (Also as reported by AL in the same
   message, SBCL depended on this nonconforming behavior to build
   itself, because of the way that **CURRENT-SEGMENT** was implemented.

-  As of sbcl-0.6.12.x, this dependence on the nonconforming behavior
+  As of sbcl-0.7.3.x, this dependence on the nonconforming behavior

   has been fixed, but the nonconforming behavior remains.)
 
 104:
   has been fixed, but the nonconforming behavior remains.)
 
 104:

@@ -912,9 +896,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

@@ -1018,36 +999,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:

@@ -1175,9 +1126,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))

@@ -1190,16 +1138,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

@@ -1220,17 +1158,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.)
 

-163:
-  HOST-NAMESTRING on a Unix pathname returns "Unix", which isn't
-  treated as a valid host by anything else in the system. (Reported by
-  Erik Naggum on comp.lang.lisp 2002-04-18)
-
-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

@@ -1252,6 +1179,62 @@ WORKAROUND:
   specialized-element-type slot in the ARRAY-TYPE structure be
   *WILD-TYPE* for UNKNOWN-TYPE element types.
 
   specialized-element-type slot in the ARRAY-TYPE structure be
   *WILD-TYPE* for UNKNOWN-TYPE element types.
 

+166:
+  Compiling 
+    (in-package :cl-user)
+    (defstruct uustk)
+    (defmethod permanentize ((uustk uustk))
+      (flet ((frob (hash-table test-for-deletion)
+               )
+             (obj-entry.stale? (oe)
+               (destructuring-bind (key . datum) oe
+                 (declare (type simple-vector key))
+                 (deny0 (void? datum))
+                 (some #'stale? key))))
+        (declare (inline frob obj-entry.stale?))
+        (frob (uustk.args-hash->obj-alist uustk)
+              #'obj-entry.stale?)
+        (frob (uustk.hash->memoized-objs-list uustk)
+              #'objs.stale?))
+      (call-next-method))
+  in sbcl-0.7.3.11 causes an assertion failure, 
+    failed AVER:
+      "(NOT
+(AND (NULL (BLOCK-SUCC B))
+      (NOT (BLOCK-DELETE-P B))
+      (NOT (EQ B (COMPONENT-HEAD #)))))"
+
+167:
+  In sbcl-0.7.3.11, compiling the (illegal) code 
+    (in-package :cl-user)
+    (defmethod prove ((uustk uustk))
+      (zap ((frob () nil))
+        (frob)))
+  gives the (not terribly clear) error message
+    ; caught ERROR:
+    ;   (during macroexpansion of (DEFMETHOD PROVE ...))
+    ; can't get template for (FROB NIL NIL)
+  The problem seems to be that the code walker used by the DEFMETHOD
+  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.
+

 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.