0.7.3.6:

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index 7f00c53..fc576e0 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -248,12 +248,6 @@ WORKAROUND:
   ANSI spec, bare 'MEMBER, 'AND, and 'OR are not legal types, CMUCL
   (and now SBCL) interpret them as legal types.
 
   ANSI spec, bare 'MEMBER, 'AND, and 'OR are not legal types, CMUCL
   (and now SBCL) interpret them as legal types.
 

-44:
-  ANSI specifies DEFINE-SYMBOL-MACRO, but it's not defined in SBCL.
-  CMU CL added it ca. Aug 13, 2000, after some discussion on the mailing
-  list, and it is probably possible to use substantially the same 
-  patches to add it to SBCL.
-

 45:
   a slew of floating-point-related errors reported by Peter Van Eynde
   on July 25, 2000:
 45:
   a slew of floating-point-related errors reported by Peter Van Eynde
   on July 25, 2000:

@@ -330,17 +324,6 @@ WORKAROUND:
        c: SYMBOL-MACROLET should signal PROGRAM-ERROR if something
           it binds is declared SPECIAL inside.
 
        c: SYMBOL-MACROLET should signal PROGRAM-ERROR if something
           it binds is declared SPECIAL inside.
 

-50:
-  type system errors reported by Peter Van Eynde July 25, 2000:
-       c: (SUBTYPEP '(INTEGER (0) (0)) 'NIL) dies with nested errors.
-       d: In general, the system doesn't like '(INTEGER (0) (0)) -- it
-          blows up at the level of SPECIFIER-TYPE with
-          "Lower bound (0) is greater than upper bound (0)." Probably
-          SPECIFIER-TYPE should return the NIL type instead.
-       g: The type system isn't all that smart about relationships
-          between hairy types, as shown in the type.erg test results,
-          e.g. (SUBTYPEP 'CONS '(NOT ATOM)) => NIL, NIL.
-

 51:
   miscellaneous errors reported by Peter Van Eynde July 25, 2000:
        a: (PROGN
 51:
   miscellaneous errors reported by Peter Van Eynde July 25, 2000:
        a: (PROGN

@@ -367,20 +350,6 @@ WORKAROUND:
   The implementation of #'+ returns its single argument without
   type checking, e.g. (+ "illegal") => "illegal".
 
   The implementation of #'+ returns its single argument without
   type checking, e.g. (+ "illegal") => "illegal".
 

-58:
-  (SUBTYPEP '(AND ZILCH INTEGER) 'ZILCH) => NIL, NIL
-  Note: I looked into fixing this in 0.6.11.15, but gave up. The
-  problem seems to be that there are two relevant type methods for
-  the subtypep operation, HAIRY :COMPLEX-SUBTYPEP-ARG2 and
-  INTERSECTION :COMPLEX-SUBTYPEP-ARG1, and only the first is
-  called. This could be fixed, but type dispatch is messy and
-  confusing enough already, I don't want to complicate it further.
-  Perhaps someday we can make CLOS cross-compiled (instead of compiled
-  after bootstrapping) so that we don't need to have the type system
-  available before CLOS, and then we can rewrite the type methods to
-  CLOS methods, and then expressing the solutions to stuff like this
-  should become much more straightforward. -- WHN 2001-03-14
-

 60:
   The debugger LIST-LOCATIONS command doesn't work properly.
 
 60:
   The debugger LIST-LOCATIONS command doesn't work properly.
 

@@ -529,18 +498,6 @@ WORKAROUND:
   it should probably look at the class name, the way that it does
   for STRUCTURE-OBJECTs.
 
   it should probably look at the class name, the way that it does
   for STRUCTURE-OBJECTs.
 

-69:
-  As reported by Martin Atzmueller on the sbcl-devel list 2000-11-22,
-  > There remains one issue, that is a bug in SBCL:
-  > According to my interpretation of the spec, the ":" and "@" modifiers
-  > should appear _after_ the comma-seperated arguments.
-  > Well, SBCL (and CMUCL for that matter) accept 
-  > (ASSERT (STRING= (FORMAT NIL "~:8D" 1) "   1"))
-  > where the correct way (IMHO) should be
-  > (ASSERT (STRING= (FORMAT NIL "~8:D" 1) "   1"))
-  Probably SBCL should stop accepting the "~:8D"-style format arguments,
-  or at least issue a warning.
-

 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

@@ -617,9 +574,6 @@ WORKAROUND:
   it would decrease efficiency more than is probably necessary. Perhaps
   using some sort of accept/reject method would be better.
 
   it would decrease efficiency more than is probably necessary. Perhaps
   using some sort of accept/reject method would be better.
 

-84:
-  (SUBTYPEP '(SATISFIES SOME-UNDEFINED-FUN) NIL)=>NIL,T (should be NIL,NIL)
-

 85:
   Internally the compiler sometimes evaluates
     (sb-kernel:type/= (specifier-type '*) (specifier-type t))
 85:
   Internally the compiler sometimes evaluates
     (sb-kernel:type/= (specifier-type '*) (specifier-type t))

@@ -640,18 +594,6 @@ WORKAROUND:
   bootstrap on a system which uses a different value of CHAR-CODE-LIMIT
   than SBCL does.
 
   bootstrap on a system which uses a different value of CHAR-CODE-LIMIT
   than SBCL does.
 

-91:
-  (subtypep '(or (integer -1 1)
-                 unsigned-byte)
-            '(or (rational -1 7)
-                 unsigned-byte
-                 (integer -1 1))) => NIL,T
-  An analogous problem with SINGLE-FLOAT and REAL types was fixed in 
-  sbcl-0.6.11.22, but some peculiarites of the RATIO type make it 
-  awkward to generalize the fix to INTEGER and RATIONAL. It's not 
-  clear what's the best fix. (See the "bug in type handling" discussion
-  on cmucl-imp ca. 2001-03-22 and ca. 2001-02-12.)
-

 94a: 
   Inconsistencies between derived and declared VALUES return types for
   DEFUN aren't checked very well. E.g. the logic which successfully
 94a: 
   Inconsistencies between derived and declared VALUES return types for
   DEFUN aren't checked very well. E.g. the logic which successfully

@@ -1117,6 +1059,11 @@ WORKAROUND:
   T
   T
 
   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:

@@ -1187,54 +1134,6 @@ WORKAROUND:
   It should be possible to be much more specific (overflow, division
   by zero, etc.) and of course the "How can this be?" should be fixable.
 
   It should be possible to be much more specific (overflow, division
   by zero, etc.) and of course the "How can this be?" should be fixable.
 

-147:
-  (reported by Alexey Dejneka sbcl-devel 2002-01-28)
-  Compiling a file containing
-    (deftype digit () '(member #\1))
-    (defun parse-num (string ind)
-      (flet ((digs ()
-               (let (old-index)
-                 (if (and (< ind ind)
-                          (typep (char string ind) 'digit))
-                     nil))))))
-  in sbcl-0.7.1 causes the compiler to fail with
-    internal error, failed AVER: "(= (LENGTH (BLOCK-SUCC CALL-BLOCK)) 1)" 
-  This problem seems to have been introduced by the sbcl-0.pre7.* compiler
-  changes, since 0.pre7.73 and 0.6.13 don't suffer from it. A related
-  test case is
-    (defun parse-num (index)
-      (let (num x)
-        (flet ((digs ()
-                 (setq num index))
-               (z ()
-                 (let ()
-                   (setq x nil))))
-          (when (and (digs) (digs)) x))))
-  In sbcl-0.7.1, this second test case failed with the same
-    internal error, failed AVER: "(= (LENGTH (BLOCK-SUCC CALL-BLOCK)) 1)" 
-  After the APD patches in sbcl-0.7.1.2 (new consistency check in
-  TARGET-IF-DESIRABLE, plus a fix in meta-vmdef.lisp to keep the
-  new consistency check from failing routinely) this second test case
-  failed in FIND-IN-PHYSENV instead. Fixes in sbcl-0.7.1.3 (not
-  closing over unreferenced variables) made this second test case
-  compile without error, but the original test case still fails.
- 
-  Another way to get rid of the DEFTYPE without changing the symptom
-  of the bug is
-    (defvar *ch*)
-    (defun parse-num (string ind)
-      (flet ((digs ()
-               (let ()
-                 (if (and (< ind ind)
-                         (sb-int:memq *ch* '(#\1)))
-                     nil))))))
-  In sbcl-0.7.1.3, this fails with
-    internal error, failed AVER: "(= (LENGTH (BLOCK-SUCC CALL-BLOCK)) 1)" 
-  The problem occurs while the inline expansion of MEMQ,
-  #<LAMBDA :%DEBUG-NAME "varargs entry point for SB-C::.ANONYMOUS.">
-  is being LET-converted after having its second REF deleted, leaving
-  it with only one entry in LEAF-REFS.
-  

 148:
   In sbcl-0.7.1.3 on x86, COMPILE-FILE on the file
     (in-package :cl-user)
 148:
   In sbcl-0.7.1.3 on x86, COMPILE-FILE on the file
     (in-package :cl-user)

@@ -1261,44 +1160,6 @@ WORKAROUND:
   issues were cleaned up. As of sbcl-0.7.1.9, it occurs in 
   NODE-BLOCK called by LAMBDA-COMPONENT called by IR2-CONVERT-CLOSURE.
 
   issues were cleaned up. As of sbcl-0.7.1.9, it occurs in 
   NODE-BLOCK called by LAMBDA-COMPONENT called by IR2-CONVERT-CLOSURE.
 

-150:
-  In sbcl-0.7.1.15, compiling this code 
-    (let* ()
-      (flet ((wufn () (glorp table1 4.9)))
-        (gleep *uustk* #'wufn "#1" (list)))
-      (if (eql (lo foomax 3.2))
-          (values)
-          (error "not ~S" '(eql (lo foomax 3.2))))
-      (values))
-  causes a failure in SB-C::ADD-TEST-CONSTRAINTS:
-    The value NIL is not of type SB-C::CONTINUATION.
-  other notes:
-    * The problem appears to be tied to the way that EQL is given only
-      one argument, and goes away when we give EQL a second argument.
-    * CMU CL 18c has this problem too, exercised by 
-       (compile nil
-                '(lambda ()
-                    (let* ()
-                     (flet ((wufn () (glorp table1 4.9)))
-                       (gleep *uustk* #'wufn "#1" (list)))
-                     (if (eql (lo foomax 3.2))
-                         (values)
-                         (error "not ~S" '(eql (lo foomax 3.2))))
-                     (values))))
-
-151:
-  From the ANSI description of GET-DISPATCH-MACRO-CHARACTER, it
-  should return NIL when there is no definition, e.g.
-    (GET-DISPATCH-MACRO-CHARACTER #\# #\{) => NIL
-  Instead, in sbcl-0.7.1.17 it returns
-    #<FUNCTION "top level local call SB!IMPL::DISPATCH-CHAR-ERROR">
-
-152:
-  Undefined functions are supposed to be reported as UNDEFINED-FUNCTION
-  conditions, inheriting from CELL-ERROR. Instead sbcl-0.7.1.19 reports
-  them as TYPE-ERRORs (reporting the problem as something not being
-  coerceable to a function).
-

 153:
   (essentially the same problem as a CMU CL bug reported by Martin
   Cracauer on cmucl-imp 2002-02-19)
 153:
   (essentially the same problem as a CMU CL bug reported by Martin
   Cracauer on cmucl-imp 2002-02-19)

@@ -1318,8 +1179,76 @@ WORKAROUND:
     Is (1 . 1) of type CONS a cons? => NIL
   without signalling an error.
 
     Is (1 . 1) of type CONS a cons? => NIL
   without signalling an error.
 

+154:
+  There's some sort of problem with aborting back out of the debugger
+  after a %DETECT-STACK-EXHAUSTION error in sbcl-0.7.1.38. In some cases
+  telling the debugger to ABORT doesn't get you back to the main REPL,
+  but instead just gives you another stack exhaustion error. The problem
+  doesn't occur in the trivial case
+    * (defun frob () (frob) (frob))
+    FROB
+    * (frob)
+  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))
+    debugger invoked on condition of type TYPE-ERROR:
+      The value NIL is not of type SB-C::DEBUG-SOURCE
+  (reported by Alexey Dejneka sbcl-devel 2002-04-12)
+
+157:
+  Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and 
+  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
+  debugger to be entered, the uninitialized slots in the bad call frame 
+  seem to cause GCish problems, being interpreted as tagged data even
+  though they're not. In particular, executing ROOM in the
+  debugger at that point causes AVER failures:
+    * (machine-type)
+    "X86"
+    * (lisp-implementation-version)
+    "0.7.2.12"
+    * (typep 10)
+    ...
+    0] (room)
+    ...
+    failed AVER: "(SAP= CURRENT END)"
+  (Christophe Rhodes reports that this doesn't occur on the SPARC, which
+  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).
+

 
 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.

-    The # values reached 6 before the category was closed down.
\ No newline at end of file
+    The # values reached 6 before the category was closed down.