0.6.11.29:
[sbcl.git] / BUGS
diff --git a/BUGS b/BUGS
index 8a88aeb..37e8fed 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -104,7 +104,10 @@ WORKAROUND:
   The situation is complicated by the presence of Common Lisp types
   like UNSIGNED-BYTE (which can either be used in list form or alone)
   so I'm not 100% sure that the behavior above is actually illegal.
-  But I'm 90+% sure, and someday perhaps I'll be motivated to look it up..
+  But I'm 90+% sure, and the following related behavior,
+       (TYPEP 11 'AND) => T
+  treating the bare symbol AND as equivalent to '(AND), is specifically
+  forbidden (by the ANSI specification of the AND type).
 
 11:
   It would be nice if the
@@ -115,25 +118,6 @@ WORKAROUND:
          (during macroexpansion of IN-PACKAGE,
          during macroexpansion of DEFFOO)
 
-12:
-  The type system doesn't understand the KEYWORD type very well:
-       (SUBTYPEP 'KEYWORD 'SYMBOL) => NIL, NIL
-  It might be possible to fix this by changing the definition of
-  KEYWORD to (AND SYMBOL (SATISFIES KEYWORDP)), but the type system
-  would need to be a bit smarter about AND types, too:
-       (SUBTYPEP '(AND SYMBOL KEYWORD) 'SYMBOL) => NIL, NIL
-  (The type system does know something about AND types already,
-       (SUBTYPEP '(AND INTEGER FLOAT) 'NUMBER) => T, T
-       (SUBTYPEP '(AND INTEGER FIXNUM) 'NUMBER) =>T, T
-  so likely this is a small patch.)
-
-13:
-  Floating point infinities are screwed up. [When I was converting CMU CL
-  to SBCL, I was looking for complexity to delete, and I thought it was safe
-  to just delete support for floating point infinities. It wasn't: they're
-  generated by the floating point hardware even when we remove support
-  for them in software. -- WHN] Support for them should be restored.
-
 14:
   The ANSI syntax for non-STANDARD method combination types in CLOS is
        (DEFGENERIC FOO (X) (:METHOD-COMBINATION PROGN))
@@ -372,9 +356,7 @@ returning an array as first value always.
 45:
   a slew of floating-point-related errors reported by Peter Van Eynde
   on July 25, 2000:
-       a: (SQRT -9.0) fails, because SB-KERNEL::COMPLEX-SQRT is undefined.
-          Similarly, COMPLEX-ASIN, COMPLEX-ACOS, COMPLEX-ACOSH, and others
-          aren't found.
+       a: (fixed in sbcl-0.6.11.25)
        b: SBCL's value for LEAST-POSITIVE-SHORT-FLOAT is bogus, and 
           should probably be 1.4012985e-45. In SBCL,
           (/ LEAST-POSITIVE-SHORT-FLOAT 2) returns a number smaller
@@ -388,10 +370,7 @@ returning an array as first value always.
                (EXPT 10.0d0 1000)
           PVE's regression tests want them to raise errors. SBCL
           generates the infinities instead, which may or may not be
-          conforming behavior, but then blow it by being unable to
-          output the infinities, since support for infinities is generally
-          broken, and in particular SB-IMPL::OUTPUT-FLOAT-INFINITY is
-          undefined.
+          conforming behavior.
        d: (in section12.erg) various forms a la 
                (FLOAT 1 DOUBLE-FLOAT-EPSILON)
           don't give the right behavior.
@@ -532,8 +511,18 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
    #<Closure Over Function "DEFUN (SETF MACRO-FUNCTION)" {480E21B1}> was defined in a non-null environment.
 
 58:
-  (SUBTYPEP '(AND ZILCH INTEGER) 'ZILCH)
-  => NIL, NIL
+  (SUBTYPEP '(AND ZILCH INTEGER) 'ZILCH) => NIL, NIL
+  Note: I looked into fixing this in 0.6.11.15, but gave up. The
+  problem seems to be that there are two relevant type methods for
+  the subtypep operation, HAIRY :COMPLEX-SUBTYPEP-ARG2 and
+  INTERSECTION :COMPLEX-SUBTYPEP-ARG1, and only the first is
+  called. This could be fixed, but type dispatch is messy and
+  confusing enough already, I don't want to complicate it further.
+  Perhaps someday we can make CLOS cross-compiled (instead of compiled
+  after bootstrapping) so that we don't need to have the type system
+  available before CLOS, and then we can rewrite the type methods to
+  CLOS methods, and then expressing the solutions to stuff like this
+  should become much more straightforward. -- WHN 2001-03-14
 
 59:
   CL:*DEFAULT-PATHNAME-DEFAULTS* doesn't behave as ANSI suggests (reflecting
@@ -787,6 +776,97 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
     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
+  used to implement CLOS methods. E.g. the output of 
+  (DESCRIBE 'PRINT-OBJECT) lists functions like 
+       #<FUNCTION "DEF!STRUCT (TRACE-INFO (:MAKE-LOAD-FORM-FUN SB-KERNEL:JUST-DUMP-IT-NORMALLY) (:PRINT-OBJECT #))" {1020E49}> 
+  and
+       #<FUNCTION "MACROLET ((FORCE-DELAYED-DEF!METHODS NIL #))" {1242871}>
+  It would be better if these functions' names always identified
+  them as methods, and identified their generic functions and
+  specializers.
+
+83:
+  RANDOM-INTEGER-EXTRA-BITS=10 may not be large enough for the RANDOM
+  RNG to be high quality near RANDOM-FIXNUM-MAX; it looks as though
+  the mean of the distribution can be systematically O(0.1%) wrong.
+  Just increasing R-I-E-B is probably not a good solution, since
+  it would decrease efficiency more than is probably necessary. Perhaps
+  using some sort of accept/reject method would be better.
+
+84:
+  (SUBTYPEP '(SATISFIES SOME-UNDEFINED-FUN) NIL)=>NIL,T (should be NIL,NIL)
+
+85:
+  Internally the compiler sometimes evaluates
+    (sb-kernel:type/= (specifier-type '*) (specifier-type t))
+  (I stumbled across this when I added an
+    (assert (not (eq type1 *wild-type*)))
+  in the NAMED :SIMPLE-= type method.) '* isn't really a type, and
+  in a type context should probably be translated to T, and so it's
+  probably to ask whether it's equal to the T type and then (using the
+  EQ type comparison in the NAMED :SIMPLE-= type method) return NIL.
+  (I haven't tried to investigate this bug enough to guess whether
+  there might be any user-level symptoms.)
+
+87:
+  Despite what the manual says, (DECLAIM (SPEED 0)) doesn't cause
+  things to be byte compiled. This seems to be true in cmucl-2.4.19,
+  too: (COMPILE-FILE .. :BYTE-COMPILE T) causes byte-compilation,
+  but ordinary COMPILE-FILE of a file containing (DECLAIM (SPEED 0))
+  does not.
+
+90: 
+  a latent cross-compilation/bootstrapping bug: The cross-compilation
+  host's CL:CHAR-CODE-LIMIT is used in target code in readtable.lisp
+  and possibly elsewhere. Instead, we should use the target system's
+  CHAR-CODE-LIMIT. This will probably cause problems if we try to 
+  bootstrap on a system which uses a different value of CHAR-CODE-LIMIT
+  than SBCL does.
+
+91:
+  (subtypep '(or (integer -1 1)
+                 unsigned-byte)
+            '(or (rational -1 7)
+                 unsigned-byte
+                 (integer -1 1))) => NIL,T
+  An analogous problem with SINGLE-FLOAT and REAL types was fixed in 
+  sbcl-0.6.11.22, but some peculiarites of the RATIO type make it 
+  awkward to generalize the fix to INTEGER and RATIONAL. It's not 
+  clear what's the best fix. (See the "bug in type handling" discussion
+  on cmucl-imp ca. 2001-03-22 and ca. 2001-02-12.)
+
+93:
+  In sbcl-0.6.11.26, (COMPILE 'IN-HOST-COMPILATION-MODE) in
+  src/cold/shared.lisp doesn't correctly translate the
+  interpreted function
+    (defun in-host-compilation-mode (fn)
+      (let ((*features* (cons :sb-xc-host *features*))
+            ;; the CROSS-FLOAT-INFINITY-KLUDGE, as documented in
+            ;; base-target-features.lisp-expr:
+            (*shebang-features* (set-difference *shebang-features*
+                                                '(:sb-propagate-float-type
+                                                  :sb-propagate-fun-type))))
+        (with-additional-nickname ("SB-XC" "SB!XC")
+          (funcall fn))))
+  No error is reported by the compiler, but when the function is executed,
+  it causes an error
+    TYPE-ERROR in SB-KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
+      (:LINUX :X86 :IEEE-FLOATING-POINT :SB-CONSTRAIN-FLOAT-TYPE :SB-TEST
+       :SB-INTERPRETER :SB-DOC :UNIX ...) is not of type SYMBOL.
+
+94: 
+  As reported by Christophe Rhodes on sbcl-devel 2001-03-28, the
+  old declaration 
+   (declaim (ftype (function (list list symbol t) list) parse-deftransform))
+  above DEFUN PARSE-DEFTRANSFORM was incorrect. The bad declaration was
+  removed in sbcl-0.6.11.28, but the compiler problem remains: the compiler
+  should've complained about the mismatch between the declaration and the
+  definition, and didn't. (The compiler in cmucl-2.5.1 does detect the 
+  problem and complain.)
+
 
 KNOWN BUGS RELATED TO THE IR1 INTERPRETER