NJF DOLIST/MACROLET patch for vmtran (sbcl-devel 2002-01-07,
[sbcl.git] / BUGS
diff --git a/BUGS b/BUGS
index e50ba73..a833316 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -126,45 +126,9 @@ WORKAROUND:
   (Also, when this is fixed, we can enable the code in PROCLAIM which 
   checks for incompatible FTYPE redeclarations.)
 
-18:
-  from DTC on the CMU CL mailing list 25 Feb 2000:
-;;; Compiler fails when this file is compiled.
-;;;
-;;; Problem shows up in delete-block within ir1util.lisp. The assertion
-;;; (assert (member (functional-kind lambda) '(:let :mv-let :assignment)))
-;;; fails within bind node branch.
-;;;
-;;; Note that if c::*check-consistency* is enabled then an un-reached
-;;; entry is also reported.
-;;;
-(defun foo (val)
-  (declare (values nil))
-  nil)
-(defun bug (val)
-  (multiple-value-call
-      #'(lambda (res)
-          (block nil
-            (tagbody
-             loop
-               (when res
-                 (return nil))
-               (go loop))))
-    (foo val))
-  (catch 'ccc1
-    (throw 'ccc1
-      (block bbbb
-        (tagbody
-
-           (let ((ttt #'(lambda () (go cccc))))
-             (declare (special ttt))
-             (return-from bbbb nil))
-
-         cccc
-           (return-from bbbb nil))))))
-
 19:
   (I *think* this is a bug. It certainly seems like strange behavior. But
-  the ANSI spec is scary, dark, and deep..)
+  the ANSI spec is scary, dark, and deep.. -- WHN)
     (FORMAT NIL  "~,1G" 1.4) => "1.    "
     (FORMAT NIL "~3,1G" 1.4) => "1.    "
 
@@ -191,24 +155,6 @@ WORKAROUND:
        Process inferior-lisp exited abnormally with code 1
   I haven't noticed a repeatable case of this yet.
 
-29:
-  some sort of bug in inlining and RETURN-FROM in sbcl-0.6.5: Compiling
-    (DEFUN BAR? (X)
-      (OR (NAR? X)
-          (BLOCK USED-BY-SOME-Y?
-            (FLET ((FROB (STK)
-                     (DOLIST (Y STK)
-                       (UNLESS (REJECTED? Y)
-                         (RETURN-FROM USED-BY-SOME-Y? T)))))
-              (DECLARE (INLINE FROB))
-              (FROB (RSTK X))
-              (FROB (MRSTK X)))
-            NIL)))
-  gives
-   error in function SB-KERNEL:ASSERT-ERROR:
-   The assertion (EQ (SB-C::CONTINUATION-KIND SB-C::CONT) :BLOCK-START) failed.
-  This is still present in sbcl-0.6.8.
-
 31:
   In some cases the compiler believes type declarations on array
   elements without checking them, e.g.
@@ -1282,90 +1228,30 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   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/*.*").
+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
 
 
 KNOWN BUGS RELATED TO THE IR1 INTERPRETER