0.pre7.111:
[sbcl.git] / BUGS
diff --git a/BUGS b/BUGS
index 3231df6..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
-  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.
-  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 
-    (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)))
-  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
@@ -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.
-       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.
@@ -389,10 +386,6 @@ WORKAROUND:
 
 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
@@ -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.
-       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.
@@ -430,14 +421,6 @@ WORKAROUND:
   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".
@@ -653,21 +636,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
 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
@@ -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.
 
-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
@@ -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.
 
-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,
@@ -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.)
 
-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:
@@ -909,12 +857,8 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
 
 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
@@ -1193,14 +1137,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   structure classes related by inheritance. As of 0.7.0, SBCL still 
   doesn't follow it.
 
-128:
-  READ-SEQUENCE doesn't work for Gray streams. (reported by Nathan
-  Froyd sbcl-devel 2001-10-15) As per subsequent discussion on the 
-  list, the Gray streams proposal doesn't mention READ-SEQUENCE and
-  WRITE-SEQUENCE because it predates them, generalizing it to 
-  cover them is an obvious extension, ACL does it, and there's a 
-  patch for for CMU CL which does it too.
-
 129:
   insufficient syntax checking in MACROLET:
    (defun foo (x)
@@ -1315,17 +1251,123 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   types manually, allowing the special case (VALUES) but still excluding
   all more-complex VALUES types.
 
-134:
-  (reported by Alexey Dejneka sbcl-devel 2001-12-07)
-    (let ((s '((1 2 3))))
-      (eval (eval ``(vector ,@',@s))))
-      
-    should return #(1 2 3), instead of this it causes a reader error.
-      
-    Interior call of BACKQUOTIFY erroneously optimizes ,@': it immediately
-    splices the temporal representation of ,@S.
-    
+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
 
 (Now that the IR1 interpreter has gone away, these should be