0.6.12.49:
[sbcl.git] / BUGS
diff --git a/BUGS b/BUGS
index ce864fd..fb0ced3 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -183,28 +183,6 @@ WORKAROUND:
        munge12egnum
        NIL
 
        munge12egnum
        NIL
 
-23:
-  When too many files are opened, OPEN will fail with an
-  uninformative error message 
-       error in function OPEN: error opening #P"/tmp/foo.lisp": NIL
-  instead of saying that too many files are open.
-
-24:
-  Right now, when COMPILE-FILE has a read error, it actually pops
-  you into the debugger before giving up on the file. It should
-  instead handle the error, perhaps issuing (and handling)
-  a secondary error "caught ERROR: unrecoverable error during compilation"
-  and then return with FAILURE-P true,
-
-26:
-  reported by Sam Steingold on the cmucl-imp mailing list 12 May 2000:
-    Also, there is another bug: `array-displacement' should return an
-    array or nil as first value (as per ANSI CL), while CMUCL declares
-    it as returning an array as first value always.
-  (Actually, I think the old CMU CL version in SBCL never returns NIL,
-  i.e. it's not just a declaration problem, but the definition doesn't
-  behave ANSIly.)
-
 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
@@ -288,6 +266,8 @@ WORKAROUND:
   that arbitrary functions check their argument types. (It might
   make sense to add another flag (CHECKED?) to DEFKNOWN to 
   identify functions which *do* check their argument types.)
   that arbitrary functions check their argument types. (It might
   make sense to add another flag (CHECKED?) to DEFKNOWN to 
   identify functions which *do* check their argument types.)
+  (Also, verify that the compiler handles declared function
+  return types as assertions.)
 
 38:
   DEFMETHOD doesn't check the syntax of &REST argument lists properly,
 
 38:
   DEFMETHOD doesn't check the syntax of &REST argument lists properly,
@@ -473,11 +453,6 @@ SBCL: (("blah") ("blah2"))
   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".
 
-55:
-  In sbcl-0.6.7, there is no doc string for CL:PUSH, probably 
-  because it's defined with the DEFMACRO-MUNDANELY macro and something
-  is wrong with doc string setting in that macro.
-
 56:
   Attempting to use COMPILE on something defined by DEFMACRO fails:
        (DEFMACRO FOO (X) (CONS X X))
 56:
   Attempting to use COMPILE on something defined by DEFMACRO fails:
        (DEFMACRO FOO (X) (CONS X X))
@@ -499,13 +474,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   CLOS methods, and then expressing the solutions to stuff like this
   should become much more straightforward. -- WHN 2001-03-14
 
   CLOS methods, and then expressing the solutions to stuff like this
   should become much more straightforward. -- WHN 2001-03-14
 
-59:
-  CL:*DEFAULT-PATHNAME-DEFAULTS* doesn't behave as ANSI suggests (reflecting
-  current working directory). And there's no supported way to update
-  or query the current working directory (a la Unix "chdir" and "pwd"),
-  which is functionality that ILISP needs (and currently gets with low-level
-  hacks).
-
 60:
   The debugger LIST-LOCATIONS command doesn't work properly.
 
 60:
   The debugger LIST-LOCATIONS command doesn't work properly.
 
@@ -570,7 +538,7 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   rightward of the correct location.
 
 65:
   rightward of the correct location.
 
 65:
-  (probably related to bug #70)
+  (probably related to bug #70; maybe related to bug #109)
   As reported by Carl Witty on submit@bugs.debian.org 1999-05-08,
   compiling this file
 (in-package "CL-USER")
   As reported by Carl Witty on submit@bugs.debian.org 1999-05-08,
   compiling this file
 (in-package "CL-USER")
@@ -667,7 +635,7 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   or at least issue a warning.
 
 70:
   or at least issue a warning.
 
 70:
-  (probably related to bug #65)
+  (probably related to bug #65; maybe related to bug #109)
   The compiler doesn't like &OPTIONAL arguments in LABELS and FLET
   forms. E.g.
     (DEFUN FIND-BEFORE (ITEM SEQUENCE &KEY (TEST #'EQL))
   The compiler doesn't like &OPTIONAL arguments in LABELS and FLET
   forms. E.g.
     (DEFUN FIND-BEFORE (ITEM SEQUENCE &KEY (TEST #'EQL))
@@ -920,6 +888,193 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   the first time around, until regression tests are written I'm not 
   comfortable merging the patches in the CVS version of SBCL.
 
   the first time around, until regression tests are written I'm not 
   comfortable merging the patches in the CVS version of SBCL.
 
+101:
+  The error message for calls to structure accessors with the
+  wrong number of arguments is confusing and of the wrong
+  condition class (TYPE-ERROR instead of PROGRAM-ERROR):
+    * (defstruct foo x y)
+    * (foo-x)
+    debugger invoked on condition of type SIMPLE-TYPE-ERROR:
+    Structure for accessor FOO-X is not a FOO:
+    301988783
+
+102:
+  As reported by Arthur Lemmens sbcl-devel 2001-05-05, ANSI
+  requires that SYMBOL-MACROLET refuse to rebind special variables,
+  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
+  has been fixed, but the nonconforming behavior remains.)
+
+103:
+  As reported by Arthur Lemmens sbcl-devel 2001-05-05, ANSI's
+  definition of (LOOP .. DO ..) requires that the terms following
+  DO all be compound forms. SBCL's implementation of LOOP allows
+  non-compound forms (like the bare symbol COUNT, in his example)
+  here.
+
+104:
+  (DESCRIBE 'SB-ALIEN:DEF-ALIEN-TYPE) reports the macro argument list
+  incorrectly:
+       DEF-ALIEN-TYPE is
+         an external symbol
+         in #<PACKAGE "SB-ALIEN">.
+       Macro-function: #<FUNCTION "DEF!MACRO DEF-ALIEN-TYPE" {19F4A39}>
+         Macro arguments:  (#:whole-470 #:environment-471)
+         On Sat, May 26, 2001 09:45:57 AM CDT it was compiled from:
+         /usr/stuff/sbcl/src/code/host-alieneval.lisp
+           Created: Monday, March 12, 2001 07:47:43 AM CST
+
+105:
+  (DESCRIBE 'STREAM-READ-BYTE)
+
+106:
+  (reported by Eric Marsden on cmucl-imp 2001-06-15)
+  Executing 
+    (TYPEP 0 '(COMPLEX (EQL 0)))
+  signals an error in sbcl-0.6.12.34, 
+    The component type for COMPLEX is not numeric: (EQL 0)
+  This is funny since sbcl-0.6.12.34 knows
+    (SUBTYPEP '(EQL 0) 'NUMBER) => T
+
+108:
+  (TIME (ROOM T)) reports more than 200 Mbytes consed even for
+  a clean, just-started SBCL system. And it seems to be right:
+  (ROOM T) can bring a small computer to its knees for a *long*
+  time trying to GC afterwards. Surely there's some more economical
+  way to implement (ROOM T).
+
+109:
+  reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
+  collection:
+    ;;; This file fails to compile.
+    ;;; Maybe this bug is related to bugs #65, #70 in the BUGS file.
+    (in-package :cl-user)
+    (defun tst2 ()
+      (labels 
+          ((eff (&key trouble)
+             (eff)
+             ;; nil
+             ;; Uncomment and it works
+             ))
+        (eff)))
+  In SBCL 0.6.12.42, the problem is
+    internal error, failed AVER:
+      "(COMMON-LISP:EQ (SB!C::LAMBDA-TAIL-SET SB!C::CALLER)
+                  (SB!C::LAMBDA-TAIL-SET (SB!C::LAMBDA-HOME SB!C::CALLEE)))"
+
+110:
+  reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
+  collection:
+    ;;; The compiler is flushing the argument type test, and the default
+    ;;; case in the cond, so that calling with say a fixnum 0 causes a
+    ;;; SIGBUS.
+    (declaim (optimize (safety 2) (speed 3)))
+    (defun tst (x)
+      (declare (type (or string stream) x))
+      (cond ((typep x 'string) 'string)
+            ((typep x 'stream) 'stream)
+            (t
+             'none)))
+  The symptom in sbcl-0.6.12.42 on OpenBSD is actually (TST 0)=>STREAM
+  (not the SIGBUS reported in the comment) but that's broken too; 
+  type declarations are supposed to be treated as assertions unless
+  SAFETY 0, so we should be getting a TYPE-ERROR.
+
+111:
+  reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
+  collection:
+    (in-package :cl-user)
+    ;;; Produces an assertion failures when compiled.
+    (defun foo (z)
+      (declare (type (or (function (t) t) null) z))
+      (let ((z (or z #'identity)))
+        (declare (type (function (t) t) z))
+        (funcall z 1)))
+  The error in sbcl-0.6.12.42 is
+    internal error, failed AVER:
+      "(COMMON-LISP:NOT (COMMON-LISP:EQ SB!C::CHECK COMMON-LISP:T))"
+
+112:
+  reported by Martin Atzmueller 2001-06-25; taken from CMU CL bugs
+  collection; apparently originally reported by Bruno Haible
+    (in-package :cl-user)
+    ;;; From: Bruno Haible
+    ;;; Subject: scope of SPECIAL declarations
+    ;;; It seems CMUCL has a bug relating to the scope of SPECIAL
+    ;;; declarations.  I observe this with "CMU Common Lisp 18a x86-linux
+    ;;; 1.4.0 cvs".
+    (let ((x 0))
+      (declare (special x))
+      (let ((x 1))
+        (let ((y x))
+          (declare (special x)) y)))
+    ;;; Gives: 0 (this should return 1 according to CLHS)
+    (let ((x 0))
+      (declare (special x))
+      (let ((x 1))
+        (let ((y x) (x 5))
+          (declare (special x)) y)))
+    ;;; Gives: 1 (correct).
+  The reported results match what we get from the interpreter
+  in sbcl-0.6.12.42.
+
+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">
+
+114:
+  reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
+  collection:
+    (in-package :cl-user)
+    ;;; This file causes the byte compiler to fail.
+    (declaim (optimize (speed 0) (safety 1)))
+    (defun tst1 ()
+      (values
+        (multiple-value-list
+         (catch 'a
+          (return-from tst1)))))
+  The error message in sbcl-0.6.12.42 is
+    internal error, failed AVER:
+      "(COMMON-LISP:EQUAL (SB!C::BYTE-BLOCK-INFO-START-STACK SB!INT:INFO) SB!C::STACK)"
+
+115:
+  reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
+  collection:
+    (in-package :cl-user)
+    ;;; The following invokes a compiler error.
+    (declaim (optimize (speed 2) (debug 3)))
+    (defun tst ()
+      (flet ((m1 ()
+               (unwind-protect nil)))
+        (if (catch nil)
+          (m1)
+          (m1))))
+  The error message in sbcl-0.6.12.42 is
+    internal error, failed AVER:
+      "(COMMON-LISP:EQ (SB!C::TN-ENVIRONMENT SB!C:TN) SB!C::TN-ENV)"
+
+116:
+  The error message from compiling
+    (LAMBDA (X) (LET ((NIL 1)) X))
+  is
+
 
 KNOWN BUGS RELATED TO THE IR1 INTERPRETER
 
 
 KNOWN BUGS RELATED TO THE IR1 INTERPRETER
 
@@ -993,3 +1148,15 @@ IR1-4:
   EVAL-WHEN is rewritten, which won't happen until after the IR1
   interpreter is gone, the system's notion of what's a top-level form
   and what's not will remain too confused to fix this problem.]
   EVAL-WHEN is rewritten, which won't happen until after the IR1
   interpreter is gone, the system's notion of what's a top-level form
   and what's not will remain too confused to fix this problem.]
+
+IR1-5:
+  (not really a bug, just a wishlist thing which might be easy
+  when EVAL-WHEN is rewritten..) It might be good for the cross-compiler
+  to warn about nested EVAL-WHENs. (In ordinary compilation, they're
+  quite likely to be OK, but in cross-compiled code EVAL-WHENs
+  are a great source of confusion, so a style warning about anything
+  unusual could be helpful.)
+
+IR1-6:
+  (another wishlist thing..) Reimplement DEFMACRO to be basically
+  like DEFMACRO-MUNDANELY, just using EVAL-WHEN.