0.pre7.111:
[sbcl.git] / BUGS
diff --git a/BUGS b/BUGS
index 2c29d33..e50ba73 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -50,31 +50,33 @@ WORKAROUND:
   believers in ANSI compatibility and all, (1) there's no obvious
   simple way to do it (short of disabling all warnings for type
   mismatches everywhere), and (2) there's a good portable
   believers in ANSI compatibility and all, (1) there's no obvious
   simple way to do it (short of disabling all warnings for type
   mismatches everywhere), and (2) there's a good portable
-  workaround. ANSI justifies this specification by saying 
+  workaround, and (3) by their own reasoning, it looks as though
+  ANSI may have gotten it wrong. ANSI justifies this specification
+  by saying 
     The restriction against issuing a warning for type mismatches
     between a slot-initform and the corresponding slot's :TYPE
     option is necessary because a slot-initform must be specified
     in order to specify slot options; in some cases, no suitable
     default may exist.
     The restriction against issuing a warning for type mismatches
     between a slot-initform and the corresponding slot's :TYPE
     option is necessary because a slot-initform must be specified
     in order to specify slot options; in some cases, no suitable
     default may exist.
-  In SBCL, as in CMU CL (or, for that matter, any compiler which
-  really understands Common Lisp types) a suitable default does
-  exist, in all cases, because the compiler understands the concept
-  of functions which never return (i.e. has return type NIL, e.g.
-  ERROR). Thus, as a portable workaround, you can use a call to
-  some known-never-to-return function as the default. E.g.
+  However, in SBCL (as in CMU CL or, for that matter, any compiler
+  which really understands Common Lisp types) a suitable default
+  does exist, in all cases, because the compiler understands the
+  concept of functions which never return (i.e. has return type NIL).
+  Thus, as a portable workaround, you can use a call to some
+  known-never-to-return function as the default. E.g.
     (DEFSTRUCT FOO
       (BAR (ERROR "missing :BAR argument")
            :TYPE SOME-TYPE-TOO-HAIRY-TO-CONSTRUCT-AN-INSTANCE-OF))
   or 
     (DEFSTRUCT FOO
       (BAR (ERROR "missing :BAR argument")
            :TYPE SOME-TYPE-TOO-HAIRY-TO-CONSTRUCT-AN-INSTANCE-OF))
   or 
-    (DECLAIM (FTYPE () NIL) MISSING-ARG) 
+    (DECLAIM (FTYPE (FUNCTION () NIL) MISSING-ARG))
     (DEFUN REQUIRED-ARG () ; workaround for SBCL non-ANSI slot init typing
       (ERROR "missing required argument")) 
     (DEFSTRUCT FOO
       (BAR (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT)
       (BLETCH (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT)
       (N-REFS-SO-FAR 0 :TYPE (INTEGER 0)))
     (DEFUN REQUIRED-ARG () ; workaround for SBCL non-ANSI slot init typing
       (ERROR "missing required argument")) 
     (DEFSTRUCT FOO
       (BAR (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT)
       (BLETCH (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT)
       (N-REFS-SO-FAR 0 :TYPE (INTEGER 0)))
-  Such code will compile without complaint and work correctly either
-  on SBCL or on a completely compliant Common Lisp system.
+  Such code should compile without complaint and work correctly either
+  on SBCL or on any other completely compliant Common Lisp system.
 
 6:
   bogus warnings about undefined functions for magic functions like
 
 6:
   bogus warnings about undefined functions for magic functions like
@@ -343,11 +345,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.
-       d: ELT signals SIMPLE-ERROR if its index argument
-          isn't a valid index for its sequence argument, but should 
-          signal TYPE-ERROR instead.
-       e: FILE-LENGTH is supposed to signal a type error when its
-          argument is not a stream associated with a file, but doesn't.
        f: (FLOAT-RADIX 2/3) should signal an error instead of 
           returning 2.
        g: (LOAD "*.lsp") should signal FILE-ERROR.
        f: (FLOAT-RADIX 2/3) should signal an error instead of 
           returning 2.
        g: (LOAD "*.lsp") should signal FILE-ERROR.
@@ -389,10 +386,6 @@ WORKAROUND:
 
 50:
   type system errors reported by Peter Van Eynde July 25, 2000:
 
 50:
   type system errors reported by Peter Van Eynde July 25, 2000:
-       a: (SUBTYPEP 'BIGNUM 'INTEGER) => NIL, NIL
-          but should be (VALUES T T) instead.
-       b: (SUBTYPEP 'EXTENDED-CHAR 'CHARACTER) => NIL, NIL
-          but should be (VALUES T T) instead.
        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
        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
@@ -402,8 +395,6 @@ WORKAROUND:
           "Component type for Complex is not numeric: (EQL 0)."
           This might be easy to fix; the type system already knows
           that (SUBTYPEP '(EQL 0) 'NUMBER) is true.
           "Component type for Complex is not numeric: (EQL 0)."
           This might be easy to fix; the type system already knows
           that (SUBTYPEP '(EQL 0) 'NUMBER) is true.
-       f: The type system doesn't know about the condition system,
-          so that e.g. (TYPEP 'SIMPLE-ERROR 'ERROR)=>NIL.
        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.
        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.
@@ -430,14 +421,6 @@ WORKAROUND:
   need to document exactly what metaobject protocol specification
   we're following -- the current code is just inherited from PCL.)
 
   need to document exactly what metaobject protocol specification
   we're following -- the current code is just inherited from PCL.)
 
-53:
-  another error from Peter Van Eynde 5 September 2000:
-  (FORMAT NIL "~F" "FOO") should work, but instead reports an error.
-  PVE submitted a patch to deal with this bug, but it exposes other
-  comparably serious bugs, so I didn't apply it. It looks as though
-  the FORMAT code needs a fair amount of rewriting in order to comply
-  with the various details of the ANSI spec.
-
 54:
   The implementation of #'+ returns its single argument without
   type checking, e.g. (+ "illegal") => "illegal".
 54:
   The implementation of #'+ returns its single argument without
   type checking, e.g. (+ "illegal") => "illegal".
@@ -653,21 +636,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
 72:
   (DECLAIM (OPTIMIZE ..)) doesn't work properly inside LOCALLY forms.
 
 72:
   (DECLAIM (OPTIMIZE ..)) doesn't work properly inside LOCALLY forms.
 
-74:
-  As noted in the ANSI specification for COERCE, (COERCE 3 'COMPLEX)
-  gives a result which isn't COMPLEX. The result type optimizer
-  for COERCE doesn't know this, perhaps because it was written before
-  ANSI threw this curveball: the optimizer thinks that COERCE always
-  returns a result of the specified type. Thus while the interpreted
-  function
-     (DEFUN TRICKY (X) (TYPEP (COERCE X 'COMPLEX) 'COMPLEX))
-  returns the correct result,
-     (TRICKY 3) => NIL
-  the compiled function
-     (COMPILE 'TRICKY)
-  does not:
-     (TRICKY 3) => T
-
 75:
   As reported by Martin Atzmueller on sbcl-devel 26 Dec 2000,
   ANSI says that WITH-OUTPUT-TO-STRING should have a keyword
 75:
   As reported by Martin Atzmueller on sbcl-devel 26 Dec 2000,
   ANSI says that WITH-OUTPUT-TO-STRING should have a keyword
@@ -694,9 +662,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   LOAD-FOREIGN, and (2) hunt for any other code which uses temporary
   files and make it share the same new safe logic.
 
   LOAD-FOREIGN, and (2) hunt for any other code which uses temporary
   files and make it share the same new safe logic.
 
-80:
-  (fixed early Feb 2001 by MNA)
-
 82: 
   Functions are assigned names based on the context in which they're
   defined. This is less than ideal for the functions which are
 82: 
   Functions are assigned names based on the context in which they're
   defined. This is less than ideal for the functions which are
@@ -866,16 +831,6 @@ 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,
 102:
   As reported by Arthur Lemmens sbcl-devel 2001-05-05, ANSI
   requires that SYMBOL-MACROLET refuse to rebind special variables,
@@ -885,13 +840,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   As of sbcl-0.6.12.x, this dependence on the nonconforming behavior
   has been fixed, but the nonconforming behavior remains.)
 
   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:
 104:
   (DESCRIBE 'SB-ALIEN:DEF-ALIEN-TYPE) reports the macro argument list
   incorrectly:
@@ -909,12 +857,8 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
 
 106:
   (reported by Eric Marsden on cmucl-imp 2001-06-15)
 
 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
+  (and APD pointed out on sbcl-devel 2001-12-29 that it's the same
+  as bug 50e)
 
 108:
   (TIME (ROOM T)) reports more than 200 Mbytes consed even for
 
 108:
   (TIME (ROOM T)) reports more than 200 Mbytes consed even for
@@ -1193,6 +1137,236 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   structure classes related by inheritance. As of 0.7.0, SBCL still 
   doesn't follow it.
 
   structure classes related by inheritance. As of 0.7.0, SBCL still 
   doesn't follow it.
 
+129:
+  insufficient syntax checking in MACROLET:
+   (defun foo (x)
+     (macrolet ((defmacro bar (z) `(+ z z)))
+       (bar x)))
+  shouldn't compile without error (because of the extra DEFMACRO symbol).
+
+130:
+  reported by Alexey Dejneka on sbcl-devel 2001-11-03
+   (defun x (x)
+     "Return X if X is a non-negative integer."
+     (let ((step (lambda (%funcall)
+                   (lambda (n)
+                     (cond ((= n 0) 0)
+                           (t (1+ (funcall %funcall (1- n)))))))))
+       (funcall
+        ((lambda (a)
+           (funcall step (lambda (n)
+                           (funcall (funcall a a) n))))
+         (lambda (a)
+           (funcall step (lambda (n)
+                           (funcall (funcall a a) n)))))
+        x)))
+  This function returns its argument. But after removing percents it
+  does not work: "Result of (1- n) is not a function".
+
+131:
+  As of sbcl-0.pre7.86.flaky7.3, the cross-compiler, and probably 
+  the CL:COMPILE function (which is based on the same %COMPILE 
+  mechanism) get confused by 
+(defun sxhash (x)
+  (labels ((sxhash-number (x)
+            (etypecase x
+              (fixnum (sxhash x)) ; through DEFTRANSFORM
+              (integer (sb!bignum:sxhash-bignum x))
+              (single-float (sxhash x)) ; through DEFTRANSFORM
+              (double-float (sxhash x)) ; through DEFTRANSFORM
+              #!+long-float (long-float (error "stub: no LONG-FLOAT"))
+              (ratio (let ((result 127810327))
+                       (declare (type fixnum result))
+                       (mixf result (sxhash-number (numerator x)))
+                       (mixf result (sxhash-number (denominator x)))
+                       result))
+              (complex (let ((result 535698211))
+                         (declare (type fixnum result))
+                         (mixf result (sxhash-number (realpart x)))
+                         (mixf result (sxhash-number (imagpart x)))
+                         result))))
+          (sxhash-recurse (x &optional (depthoid +max-hash-depthoid+))
+            (declare (type index depthoid))
+            (typecase x
+              (list
+               (if (plusp depthoid)
+                   (mix (sxhash-recurse (car x) (1- depthoid))
+                        (sxhash-recurse (cdr x) (1- depthoid)))
+                   261835505))
+              (instance
+               (if (typep x 'structure-object)
+                   (logxor 422371266
+                           (sxhash ; through DEFTRANSFORM
+                            (class-name (layout-class (%instance-layout x)))))
+                   309518995))
+              (symbol (sxhash x)) ; through DEFTRANSFORM
+              (number (sxhash-number x))
+              (array
+               (typecase x
+                 (simple-string (sxhash x)) ; through DEFTRANSFORM
+                 (string (%sxhash-substring x))
+                 (bit-vector (let ((result 410823708))
+                               (declare (type fixnum result))
+                               (dotimes (i (min depthoid (length x)))
+                                 (mixf result (aref x i)))
+                               result))
+                 (t (logxor 191020317 (sxhash (array-rank x))))))
+              (character
+               (logxor 72185131
+                       (sxhash (char-code x)))) ; through DEFTRANSFORM
+              (t 42))))
+    (sxhash-recurse x)))
+  complaining "function called with two arguments, but wants exactly
+  one" about SXHASH-RECURSE. (This might not be strictly a new bug, 
+  since IIRC post-fork CMU CL has also had problems with &OPTIONAL
+  arguments in FLET/LABELS: it might be an old Python bug which is 
+  only exercised by the new arrangement of the SBCL compiler.)
+
+132:
+  Trying to compile 
+    (DEFUN FOO () (CATCH 0 (PRINT 1331)))
+  gives an error
+    #<SB-C:TN '0!1> is not valid as the second argument to VOP:
+      SB-C:MAKE-CATCH-BLOCK,
+    since the TN's primitive type SB-VM::POSITIVE-FIXNUM doesn't allow
+    any of the SCs allowed by the operand restriction:
+     (SB-VM::DESCRIPTOR-REG)
+  The (CATCH 0 ...) construct is bad style (because of unportability
+  of EQ testing of numbers) but it is legal, and shouldn't cause an
+  internal compiler error. (This error occurs in sbcl-0.6.13 and in
+  0.pre7.86.flaky7.14.)
+
+133:
+  Trying to compile something like 
+    (sb!alien:def-alien-routine "breakpoint_remove" sb!c-call:void
+      (code-obj sb!c-call:unsigned-long)
+      (pc-offset sb!c-call:int)
+      (old-inst sb!c-call:unsigned-long))
+  in SBCL-0.pre7.86.flaky7.22 after warm init fails with an error
+    cannot use values types here
+  probably because the SB-C-CALL:VOID type gets translated to (VALUES).
+  It should be valid to use VOID for a function return type, so perhaps
+  instead of calling SPECIFIER-TYPE (which excludes all VALUES types
+  automatically) we should call VALUES-SPECIFIER-TYPE and handle VALUES
+  types manually, allowing the special case (VALUES) but still excluding
+  all more-complex VALUES types.
+
+135:
+  Ideally, uninterning a symbol would allow it, and its associated
+  FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However, 
+  at least as of sbcl-0.7.0, this isn't the case. Information about
+  FDEFINITIONs and PROCLAIMed properties is stored in globaldb.lisp
+  essentially in ordinary (non-weak) hash tables keyed by symbols.
+  Thus, once a system has an entry in this system, it tends to live
+  forever, even when it is uninterned and all other references to it
+  are lost. 
+
+136:
+  (reported by Arnaud Rouanet on cmucl-imp 2001-12-18)
+    (defmethod foo ((x integer))
+      x)
+    (defmethod foo :around ((x integer))
+      (let ((x (1+ x)))
+        (call-next-method)))
+  Now (FOO 3) should return 3, but instead it returns 4.
+    
+137:
+  (SB-DEBUG:BACKTRACE) output should start with something
+  including the name BACKTRACE, not (as in 0.pre7.88)
+  just "0: (\"hairy arg processor\" ...)". Until about
+  sbcl-0.pre7.109, the names in BACKTRACE were all screwed
+  up compared to the nice useful names in sbcl-0.6.13.
+  Around sbcl-0.pre7.109, they were mostly fixed by using
+  NAMED-LAMBDA to implement DEFUN. However, there are still
+  some screwups left, e.g. as of sbcl-0.pre7.109, there are
+  still some functions named "hairy arg processor" and
+  "SB-INT:&MORE processor".
+
+138:
+  a pair of cross-compiler bugs in sbcl-0.pre7.107
+
+138a:
+  $ cat > /tmp/bug138.lisp << EOF
+  (in-package "SB!KERNEL")
+  (defun f-c-l (name parent-types)
+    (let* ((cpl (mapcar (lambda (x) 
+                          (condition-class-cpl x))
+                        parent-types))
+           (new-inherits
+             (concatenate 'simple-vector
+                          (layout-inherits cond-layout))))
+      (if (not (mismatch (layout-inherits olayout) new-inherits))
+          olayout
+          (make-layout))))
+  EOF
+  $ sbcl --core output/after-xc.core
+  ...
+  * (target-compile-file "/tmp/bug138.lisp")
+  ...
+  internal error, failed AVER:
+    "(COMMON-LISP:MEMBER SB!C::FUN (SB!C::COMPONENT-LAMBDAS SB!C:COMPONENT))"
+
+  It seems as though this xc bug is likely to correspond to a bug in the
+  ordinary compiler, but I haven't yet found a test case which causes
+  this problem in the ordinary compiler.
+
+  related weirdness: Using #'(LAMBDA (X) ...) instead of (LAMBDA (X) ...)
+  makes the assertion failure go away.
+
+138b:
+  Even when you relax the AVER that fails in 138a, there's another
+  problem cross-compiling the same code:
+    internal error, failed AVER:
+      "(COMMON-LISP:ZEROP
+ (COMMON-LISP:HASH-TABLE-COUNT
+  (SB!FASL::FASL-OUTPUT-PATCH-TABLE SB!FASL:FASL-OUTPUT)))"
+
+  The same problem appears in the simpler test case
+    (in-package "SB!KERNEL")
+    (defun f-c-l ()
+      (let ((cpl (foo (lambda (x) 
+                        (condition-class-cpl x))))
+            (new-inherits (layout-inherits cond-layout)))
+        (layout-inherits olayout)))
+
+  Changing CONDITION-CLASS-CPL or (either of the calls to) LAYOUT-INHERITS
+  to arbitrary nonmagic not-defined-yet just-do-a-full-call functions makes
+  the problem go away. Also, even in this simpler test case which fails
+  on a very different AVER, the 138a weirdness about s/(lambda/#'(lambda/
+  making the problem go away is preserved.
+
+  I still haven't found any way to make this happen in the ordinary
+  (not cross-) SBCL compiler, nor in CMU CL.
+
+138c:
+  In sbcl-0.pre7.111 I added an assertion upstream, in IR2-CONVERT-CLOSURE,
+  which fails for the test case above but doesn't keep the system
+  from cross-compiling itself or passing its tests.
+
+139:
+  In sbcl-0.pre7.107, (DIRECTORY "*.*") is broken, as reported by 
+  Nathan Froyd sbcl-devel 2001-12-28.
+
+  Christophe Rhodes suggested (sbcl-devel 2001-12-30) converting
+  the MERGED-PATHNAME expression in DEFUN DIRECTORY to
+        (merged-pathname (merge-pathnames pathname
+                                         *default-pathname-defaults*))
+  This looks right, and fixes this bug, but it interacts with the NODES
+  logic in %ENUMERATE-PATHNAMES to create a new bug, so that
+  (DIRECTORY "../**/*.*") no longer shows files in the current working
+  directory. Probably %ENUMERATE-PATHNAMES (or related logic like
+  %ENUMERATE-MATCHES) needs to be patched as well.
+
+  Note: The MERGED-PATHNAME change changes behavior incompatibly,
+  making e.g. (DIRECTORY "*") no longer equivalent to (DIRECTORY "*.*"),
+  so deserves a NEWS entry. E.g.
+* minor incompatible change (part of a bug fix by Christophe Rhodes
+  to DIRECTORY behavior): DIRECTORY no longer implicitly promotes
+  NIL slots of its pathname argument to :WILD, and in particular
+  asking for the contents of a directory, which you used to be able
+  to do without explicit wildcards, e.g. (DIRECTORY "/tmp/"), 
+  now needs explicit wildcards, e.g. (DIRECTORY "/tmp/*.*").
+
 
 KNOWN BUGS RELATED TO THE IR1 INTERPRETER
 
 
 KNOWN BUGS RELATED TO THE IR1 INTERPRETER