0.pre7.49:
[sbcl.git] / BUGS
diff --git a/BUGS b/BUGS
index fd5ebfc..5df3d1b 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -88,9 +88,9 @@ WORKAROUND:
   to really grok function declarations.
 
 7:
-  The "byte compiling top-level form:" output ought to be condensed.
+  The "compiling top-level form:" output ought to be condensed.
   Perhaps any number of such consecutive lines ought to turn into a
-  single "byte compiling top-level forms:" line.
+  single "compiling top-level forms:" line.
 
 10:
   The way that the compiler munges types with arguments together
@@ -387,18 +387,6 @@ WORKAROUND:
        c: SYMBOL-MACROLET should signal PROGRAM-ERROR if something
           it binds is declared SPECIAL inside.
 
-49:
-  LOOP bugs reported by Peter Van Eynde July 25, 2000:
-       a: (LOOP WITH (A B) DO (PRINT 1)) is a syntax error according to
-          the definition of WITH clauses given in the ANSI spec, but
-          compiles and runs happily in SBCL.
-       b: a messy one involving package iteration:
-interpreted Form: (LET ((PACKAGE (MAKE-PACKAGE "LOOP-TEST"))) (INTERN "blah" PACKAGE) (LET ((BLAH2 (INTERN "blah2" PACKAGE))) (EXPORT BLAH2 PACKAGE)) (LIST (SORT (LOOP FOR SYM BEING EACH PRESENT-SYMBOL OF PACKAGE FOR SYM-NAME = (SYMBOL-NAME SYM) COLLECT SYM-NAME) (FUNCTION STRING<)) (SORT (LOOP FOR SYM BEING EACH EXTERNAL-SYMBOL OF PACKAGE FOR SYM-NAME = (SYMBOL-NAME SYM) COLLECT SYM-NAME) (FUNCTION STRING<))))
-Should be: (("blah" "blah2") ("blah2"))
-SBCL: (("blah") ("blah2"))
-       * (LET ((X 1)) (LOOP FOR I BY (INCF X) FROM X TO 10 COLLECT I))
-         doesn't work -- SBCL's LOOP says BY isn't allowed in a FOR clause.
-
 50:
   type system errors reported by Peter Van Eynde July 25, 2000:
        a: (SUBTYPEP 'BIGNUM 'INTEGER) => NIL, NIL
@@ -709,17 +697,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
 80:
   (fixed early Feb 2001 by MNA)
 
-81:
-  As reported by wbuss@TELDA.NET (Wolfhard Buss) on cmucl-help
-  2001-02-14, 
-    According to CLHS
-        (loop with (a . b) of-type float = '(0.0 . 1.0)
-          and (c . d) of-type float = '(2.0 . 3.0)
-          return (list a b c d))
-    should evaluate to (0.0 1.0 2.0 3.0). cmucl-18c disagrees and
-    invokes the debugger: "B is not of type list".
-  SBCL does the same thing.
-
 82: 
   Functions are assigned names based on the context in which they're
   defined. This is less than ideal for the functions which are
@@ -1040,21 +1017,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
     ;   (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:
@@ -1113,42 +1075,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
    Raymond Toy comments that this is tricky on the X86 since its FPU
    uses 80-bit precision internally.
 
-119:
-   a bug in the byte compiler and/or interpreter: Compile
-       (IN-PACKAGE :CL-USER)
-       (DECLAIM (OPTIMIZE (SPEED 0) (SAFETY 1) (DEBUG 1)))
-       (DEFUN BAR (&REST DIMS)
-         (IF (EVERY #'INTEGERP DIMS)
-             1
-             2))
-   then execute (BAR '(1 2 3 4)). In sbcl-0.pre7.14.flaky4.8
-   this gives a TYPE-ERROR,
-     The value #:UNINITIALIZED-EVAL-STACK-ELEMENT is not
-       of type (MOD 536870911).
-   The same error will probably occur in earlier versions as well, 
-   although the name of the uninitialized-element placeholder will
-   be shorter.
-
-   The same thing happens if the compiler macro expansion of 
-   EVERY into MAP is hand-expanded:
-       (defun bar2 (dims)
-         (if (block blockname
-               (map nil
-                    (lambda (dim)
-                      (let ((pred-value (funcall #'integerp dim)))
-                        (unless pred-value
-                          (return-from blockname
-                            nil))))
-                    dims)      
-               t)
-             1
-             2))
-   CMU CL doesn't have this compiler macro expansion, so it was 
-   immune to the original bug in BAR, but once we hand-expand it
-   into BAR2, CMU CL 18c has the same bug. (Run (BAR '(NIL NIL)).)
-
-   The native compiler handles it fine, both in SBCL and in CMU CL.
-
 120a:
    The compiler incorrectly figures the return type of 
        (DEFUN FOO (FRAME UP-FRAME)
@@ -1240,64 +1166,32 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
    but actual specification quoted above says that the actual behavior
    is undefined.
 
+125:
+   (as reported by Gabe Garza on cmucl-help 2001-09-21)
+       (defvar *tmp* 3)
+       (defun test-pred (x y)
+         (eq x y))
+       (defun test-case ()
+         (let* ((x *tmp*)
+                (func (lambda () x)))
+           (print (eq func func))
+           (print (test-pred func func))
+           (delete func (list func))))
+   Now calling (TEST-CASE) gives output
+     NIL
+     NIL
+     (#<FUNCTION {500A9EF9}>)
+   Evidently Python thinks of the lambda as a code transformation so
+   much that it forgets that it's also an object.
+
+126:
+  (fixed in 0.pre7.41)
+
+
 KNOWN BUGS RELATED TO THE IR1 INTERPRETER
 
-(Note: At some point, the pure interpreter (actually a semi-pure
-interpreter aka "the IR1 interpreter") will probably go away, replaced
-by constructs like
-  (DEFUN EVAL (X) (FUNCALL (COMPILE NIL (LAMBDA ..)))))
-and at that time these bugs should either go away automatically or
-become more tractable to fix. Until then, they'll probably remain,
-since some of them aren't considered urgent, and the rest are too hard
-to fix as long as so many special cases remain. After the IR1
-interpreter goes away is also the preferred time to start
-systematically exterminating cases where debugging functionality
-(backtrace, breakpoint, etc.) breaks down, since getting rid of the
-IR1 interpreter will reduce the number of special cases we need to
-support.)
-
-IR1-1:
-  The FUNCTION special operator doesn't check properly whether its
-  argument is a function name. E.g. (FUNCTION (X Y)) returns a value
-  instead of failing with an error. (Later attempting to funcall the
-  value does cause an error.) 
-
-IR1-2:
-  COMPILED-FUNCTION-P bogusly reports T for interpreted functions:
-       * (DEFUN FOO (X) (- 12 X))
-       FOO
-       * (COMPILED-FUNCTION-P #'FOO)
-       T
-
-IR1-3:
-  Executing 
-    (DEFVAR *SUPPRESS-P* T)
-    (EVAL '(UNLESS *SUPPRESS-P*
-             (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
-               (FORMAT T "surprise!"))))
-  prints "surprise!". Probably the entire EVAL-WHEN mechanism ought to be
-  rewritten from scratch to conform to the ANSI definition, abandoning
-  the *ALREADY-EVALED-THIS* hack which is used in sbcl-0.6.8.9 (and
-  in the original CMU CL source, too). This should be easier to do --
-  though still nontrivial -- once the various IR1 interpreter special
-  cases are gone.
-
-IR1-3a:
-  EVAL-WHEN's idea of what's a toplevel form is even more screwed up 
-  than the example in IR1-3 would suggest, since COMPILE-FILE and
-  COMPILE both print both "right now!" messages when compiling the
-  following code,
-    (LAMBDA (X)
-      (COND (X
-             (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
-              (PRINT "yes! right now!"))
-             "yes!")
-            (T
-             (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
-               (PRINT "no! right now!"))
-             "no!")))
-  and while EVAL doesn't print the "right now!" messages, the first
-  FUNCALL on the value returned by EVAL causes both of them to be printed.
+(Now that the IR1 interpreter has gone away, these should be 
+relatively straightforward to fix.)
 
 IR1-4:
   The system accepts DECLAIM in most places where DECLARE would be