0.9.1.63:
[sbcl.git] / BUGS
diff --git a/BUGS b/BUGS
index 49b4c25..a6fca6d 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -84,34 +84,12 @@ WORKAROUND:
 
   d: (fixed in 0.8.1.5)
 
 
   d: (fixed in 0.8.1.5)
 
-7:
-  The "compiling top-level form:" output ought to be condensed.
-  Perhaps any number of such consecutive lines ought to turn into a
-  single "compiling top-level forms:" line.
-
-19:
-  (I *think* this is a bug. It certainly seems like strange behavior. But
-  the ANSI spec is scary, dark, and deep.. -- WHN)
-    (FORMAT NIL  "~,1G" 1.4) => "1.    "
-    (FORMAT NIL "~3,1G" 1.4) => "1.    "
-
 27:
   Sometimes (SB-EXT:QUIT) fails with 
        Argh! maximum interrupt nesting depth (4096) exceeded, exiting
        Process inferior-lisp exited abnormally with code 1
   I haven't noticed a repeatable case of this yet.
 
 27:
   Sometimes (SB-EXT:QUIT) fails with 
        Argh! maximum interrupt nesting depth (4096) exceeded, exiting
        Process inferior-lisp exited abnormally with code 1
   I haven't noticed a repeatable case of this yet.
 
-32:
-  The printer doesn't report closures very well. This is true in 
-  CMU CL 18b as well:
-    (defstruct foo bar)
-    (print #'foo-bar)
-  gives
-    #<FUNCTION "CLOSURE" {406974D5}>
-  It would be nice to make closures have a settable name slot,
-  and make things like DEFSTRUCT and FLET, which create closures,
-  set helpful values into this slot.
-
 33:
   And as long as we're wishing, it would be awfully nice if INSPECT could
   also report on closures, telling about the values of the bound variables.
 33:
   And as long as we're wishing, it would be awfully nice if INSPECT could
   also report on closures, telling about the values of the bound variables.
@@ -157,10 +135,6 @@ WORKAROUND:
   so they could be supported after all. Very likely 
   SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too.
 
   so they could be supported after all. Very likely 
   SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too.
 
-60:
-  The debugger LIST-LOCATIONS command doesn't work properly.
-  (How should it work properly?)
-
 61:
   Compiling and loading
     (DEFUN FAIL (X) (THROW 'FAIL-TAG X))
 61:
   Compiling and loading
     (DEFUN FAIL (X) (THROW 'FAIL-TAG X))
@@ -379,24 +353,6 @@ WORKAROUND:
    a STYLE-WARNING for references to variables similar to locals might
    be a good thing.)
 
    a STYLE-WARNING for references to variables similar to locals might
    be a good thing.)
 
-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.
-
 135:
   Ideally, uninterning a symbol would allow it, and its associated
   FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However,
 135:
   Ideally, uninterning a symbol would allow it, and its associated
   FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However,
@@ -629,18 +585,6 @@ WORKAROUND:
 211: "keywords processing"
   a. :ALLOW-OTHER-KEYS T should allow a function to receive an odd
      number of keyword arguments.
 211: "keywords processing"
   a. :ALLOW-OTHER-KEYS T should allow a function to receive an odd
      number of keyword arguments.
-  e. Compiling
-
-      (flet ((foo (&key y) (list y)))
-        (list (foo :y 1 :y 2)))
-
-     issues confusing message
-
-       ; in: LAMBDA NIL
-       ;     (FOO :Y 1 :Y 2)
-       ;
-       ; caught STYLE-WARNING:
-       ;   The variable #:G15 is defined but never used.
 
 212: "Sequence functions and circular arguments"
   COERCE, MERGE and CONCATENATE go into an infinite loop when given
 
 212: "Sequence functions and circular arguments"
   COERCE, MERGE and CONCATENATE go into an infinite loop when given
@@ -786,6 +730,11 @@ WORKAROUND:
   (UNSIGNED-BYTE 8) will write to the stream one byte at a time,
   rather than writing the sequence in one go, leading to severe
   performance degradation.
   (UNSIGNED-BYTE 8) will write to the stream one byte at a time,
   rather than writing the sequence in one go, leading to severe
   performance degradation.
+  As of sbcl-0.9.0.36, this is solved for fd-streams, so is less of a
+  problem in practice.  (Fully fixing this would require adding a
+  ansi-stream-n-bout slot and associated methods to write a byte
+  sequence to ansi-stream, similar to the existing ansi-stream-sout
+  slot/functions.)
 
 243: "STYLE-WARNING overenthusiasm for unused variables"
   (observed from clx compilation)
 
 243: "STYLE-WARNING overenthusiasm for unused variables"
   (observed from clx compilation)
@@ -931,6 +880,14 @@ WORKAROUND:
 
   (fixed in 0.8.2.51, but a test case would be good)
 
 
   (fixed in 0.8.2.51, but a test case would be good)
 
+276:
+  b. The same as in a., but using MULTIPLE-VALUE-SETQ instead of SETQ.
+  c. (defvar *faa*)
+     (defmethod faa ((*faa* double-float))
+           (set '*faa* (when (< *faa* 0) (- *faa*)))
+           (1+ *faa*))
+     (faa 1d0) => type error
+
 278:
   a.
     (defun foo ()
 278:
   a.
     (defun foo ()
@@ -967,24 +924,6 @@ WORKAROUND:
 
  (see also bug 117)
 
 
  (see also bug 117)
 
-281: COMPUTE-EFFECTIVE-METHOD error signalling.
-  (slightly obscured by a non-0 default value for
-   SB-PCL::*MAX-EMF-PRECOMPUTE-METHODS*)
-  It would be natural for COMPUTE-EFFECTIVE-METHOD to signal errors
-  when it finds a method with invalid qualifiers.  However, it
-  shouldn't signal errors when any such methods are not applicable to
-  the particular call being evaluated, and certainly it shouldn't when
-  simply precomputing effective methods that may never be called.
-  (setf sb-pcl::*max-emf-precompute-methods* 0)
-  (defgeneric foo (x)
-    (:method-combination +)
-    (:method ((x symbol)) 1)
-    (:method + ((x number)) x))
-  (foo 1) -> ERROR, but should simply return 1
-
-  The issue seems to be that construction of a discriminating function
-  calls COMPUTE-EFFECTIVE-METHOD with methods that are not all applicable.
-
 283: Thread safety: libc functions
   There are places that we call unsafe-for-threading libc functions
   that we should find alternatives for, or put locks around.  Known or
 283: Thread safety: libc functions
   There are places that we call unsafe-for-threading libc functions
   that we should find alternatives for, or put locks around.  Known or
@@ -1109,17 +1048,6 @@ WORKAROUND:
 
   The problem is that both EVALs sequentially write to the same LVAR.
 
 
   The problem is that both EVALs sequentially write to the same LVAR.
 
-305:
-  (Reported by Dave Roberts.)
-  Local INLINE/NOTINLINE declaration removes local FTYPE declaration:
-
-    (defun quux (x)
-      (declare (ftype (function () (integer 0 10)) fee)
-               (inline fee))
-      (1+ (fee)))
-
-  uses generic arithmetic with INLINE and fixnum without.
-
 306: "Imprecise unions of array types"
   a.(defun foo (x)
       (declare (optimize speed)
 306: "Imprecise unions of array types"
   a.(defun foo (x)
       (declare (optimize speed)
@@ -1170,16 +1098,6 @@ WORKAROUND:
     Expected: (2 6 15 38)
     Got:      ERROR
 
     Expected: (2 6 15 38)
     Got:      ERROR
 
-317: "FORMAT of floating point numbers"
-  reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
-  test suite.
-    (format nil "~1F" 10) => "0." ; "10." expected
-    (format nil "~0F" 10) => "0." ; "10." expected
-    (format nil "~2F" 1234567.1) => "1000000." ; "1234567." expected
-  it would be nice if whatever fixed this also untangled the two
-  competing implementations of floating point printing (Steele and
-  White, and Burger and Dybvig) present in src/code/print.lisp
-
 318: "stack overflow in compiler warning with redefined class"
   reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
   test suite.
 318: "stack overflow in compiler warning with redefined class"
   reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
   test suite.
@@ -1569,6 +1487,10 @@ WORKAROUND:
  (used on non-x86 platforms) being a more complete solution then what
  is done on x86.
 
  (used on non-x86 platforms) being a more complete solution then what
  is done on x86.
 
+ On x86/linux large portions of tests/debug.impure.lisp have been commented
+ out as failures. The probable culprit for these problems is in x86-call-context
+ (things work fine on x86/freebsd).
+
  More generally, the debugger internals suffer from excessive x86/non-x86
  conditionalization and OAOOMization: refactoring the common parts would
  be good.
  More generally, the debugger internals suffer from excessive x86/non-x86
  conditionalization and OAOOMization: refactoring the common parts would
  be good.
@@ -1581,6 +1503,13 @@ WORKAROUND:
  Has the XEP for TEST in the backtrace, not the TEST frame itself.
  (sparc and x86 at least)
 
  Has the XEP for TEST in the backtrace, not the TEST frame itself.
  (sparc and x86 at least)
 
+ Since SBCL 0.8.20.1 this is hidden unless *SHOW-ENTRY-POINT-DETAILS*
+ is true (instead there appear two TEST frames at least on ppc). The
+ underlying cause seems to be that SB-C::TAIL-ANNOTATE will not merge
+ the tail-call for the XEP, since Python has by that time proved that
+ the function can never return; same happens if the function holds an
+ unconditional call to ERROR.
+
 355: change-class of generic-function
     (reported by Bruno Haible)
   The MOP doesn't support change-class on a generic-function. However, SBCL
 355: change-class of generic-function
     (reported by Bruno Haible)
   The MOP doesn't support change-class on a generic-function. However, SBCL
@@ -2056,3 +1985,101 @@ WORKAROUND:
            (let ((i (sb-c::values-type-intersection x y)))
              (assert (sb-c::type= i (sb-c::values-type-intersection i x)))
              (assert (sb-c::type= i (sb-c::values-type-intersection i y)))))))
            (let ((i (sb-c::values-type-intersection x y)))
              (assert (sb-c::type= i (sb-c::values-type-intersection i x)))
              (assert (sb-c::type= i (sb-c::values-type-intersection i y)))))))
+
+370: reader misbehaviour on large-exponent floats
+    (read-from-string "1.0s1000000000000000000000000000000000000000")
+  causes the reader to attempt to create a very large bignum (which it
+  will then attempt to coerce to a rational).  While this isn't
+  completely wrong, it is probably not ideal -- checking the floating
+  point control word state and then returning the relevant float
+  (most-positive-short-float or short-float-infinity) or signalling an
+  error immediately would seem to make more sense.
+
+372: floating-point overflow not signalled on ppc/darwin
+ The following assertions in float.pure.lisp fail on ppc/darwin 
+ (Mac OS X version 10.3.7):
+   (assert (raises-error? (scale-float 1.0 most-positive-fixnum)
+                         floating-point-overflow))
+   (assert (raises-error? (scale-float 1.0d0 (1+ most-positive-fixnum))
+                          floating-point-overflow)))
+ as the SCALE-FLOAT just returns 
+ #.SB-EXT:SINGLE/DOUBLE-FLOAT-POSITIVE-INFINITY. These tests have been
+ disabled on Darwin for now.
+
+374: BIT-AND problem on ppc/darwin:
+  The BIT-AND test in bit-vector.impure-cload.lisp results in
+    fatal error encountered in SBCL pid 8356:
+    GC invariant lost, file "gc-common.c", line 605
+  on ppc/darwin. Test disabled for the duration.
+
+375: MISC.555
+    (compile nil '(lambda (p1)
+                   (declare (optimize (speed 1) (safety 2) (debug 2) (space 0))
+                            (type keyword p1))
+                   (keywordp p1)))
+
+  fails on hairy type check in IR2.
+
+  1. KEYWORDP is MAYBE-INLINE expanded (before TYPEP-like
+     transformation could eliminate it).
+
+  2. From the only call of KEYWORDP the type of its argument is
+     derived to be KEYWORD.
+
+  2. Type check for P1 is generated; it uses KEYWORDP to perform the
+     check, and so references the local function; from the KEYWORDP
+     argument type new CAST to KEYWORD is generated. The compiler
+     loops forever.
+
+377: Memory fault error reporting
+  On those architectures where :C-STACK-IS-CONTROL-STACK is in
+  *FEATURES*, we handle SIG_MEMORY_FAULT (SEGV or BUS) on an altstack,
+  so we cannot handle the signal directly (as in interrupt_handle_now())
+  in the case when the signal comes from some external agent (the user
+  using kill(1), or a fault in some foreign code, for instance).  As
+  of sbcl-0.8.20.20, this is fixed by calling
+  arrange_return_to_lisp_function() to a new error-signalling
+  function, but as a result the error reporting is poor: we cannot
+  even tell the user at which address the fault occurred.  We should
+  arrange such that arguments can be passed to the function called from
+  arrange_return_to_lisp_function(), but this looked hard to do in
+  general without suffering from memory leaks.
+
+379: TRACE :ENCAPSULATE NIL broken on ppc/darwin
+  See commented-out test-case in debug.impure.lisp.
+
+380: Accessor redefinition fails because of old accessor name
+  When redefining an accessor, SB-PCL::FIX-SLOT-ACCESSORS may try to
+  find the generic function named by the old accessor name using
+  ENSURE-GENERIC-FUNCTION and then remove the old accessor's method in
+  the GF. If the old name does not name a function, or if the old name
+  does not name a generic function, no attempt to find the GF or remove
+  any methods is made.
+
+  However, if an unrelated GF with an incompatible lambda list exists,
+  the class redefinition will fail when SB-PCL::REMOVE-READER-METHOD
+  tries to find and remove a method with an incompatible lambda list
+  from the unrelated generic function.
+
+381: incautious calls to EQUAL in fasl dumping
+  Compiling 
+    (frob #(#1=(a #1#)))
+    (frob #(#1=(b #1#)))
+    (frob #(#1=(a #1#)))
+  in sbcl-0.9.0 causes CONTROL-STACK-EXHAUSTED. My (WHN) impression 
+  is that this follows from the use of (MAKE-HASH-TABLE :TEST 'EQUAL)
+  to detect sharing, in which case fixing it might require either 
+  getting less ambitious about detecting shared list structure, or 
+  implementing the moral equivalent of EQUAL hash tables in a 
+  cycle-tolerant way.
+
+382: externalization unexpectedly changes array simplicity
+  COMPILE-FILE and LOAD
+    (defun foo ()
+      (let ((x #.(make-array 4 :fill-pointer 0)))
+        (values (eval `(typep ',x 'simple-array))
+                (typep x 'simple-array))))
+  then (FOO) => T, NIL.
+
+  Similar problems exist with SIMPLE-ARRAY-P, ARRAY-HEADER accessors
+  and all array dimension functions.