0.8.1.6:

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index e4dd346..7d606d7 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -84,24 +84,7 @@ WORKAROUND:
      an error may be signalled at read time and it would be good if
      SBCL did it.
 
      an error may be signalled at read time and it would be good if
      SBCL did it.
 

-  c: Reading of not initialized slot sometimes causes SEGV (for inline
-     accessors it is fixed, but out-of-line still do not perform type
-     check).
-
-  d:
-    (declaim (optimize (safety 3) (speed 1) (space 1)))
-    (defstruct foo
-      x y)
-    (defstruct (stringwise-foo (:include foo
-                                         (x "x" :type simple-string)
-                                         (y "y" :type simple-string))))
-    (defparameter *stringwise-foo*
-      (make-stringwise-foo))
-    (setf (foo-x *stringwise-foo*) 0)
-    (defun frob-stringwise-foo (sf)
-      (aref (stringwise-foo-x sf) 0))
-    (frob-stringwise-foo *stringwise-foo*)
-  SEGV.
+  d: (fixed in 0.8.1.5)

 
 7:
   The "compiling top-level form:" output ought to be condensed.
 
 7:
   The "compiling top-level form:" output ought to be condensed.

@@ -117,12 +100,6 @@ WORKAROUND:
          (during macroexpansion of IN-PACKAGE,
          during macroexpansion of DEFFOO)
 
          (during macroexpansion of IN-PACKAGE,
          during macroexpansion of DEFFOO)
 

-15:
-  (SUBTYPEP '(FUNCTION (T BOOLEAN) NIL)
-            '(FUNCTION (FIXNUM FIXNUM) NIL)) => T, T
-  (Also, when this is fixed, we can enable the code in PROCLAIM which 
-  checks for incompatible FTYPE redeclarations.)
-

 19:
   (I *think* this is a bug. It certainly seems like strange behavior. But
   the ANSI spec is scary, dark, and deep.. -- WHN)
 19:
   (I *think* this is a bug. It certainly seems like strange behavior. But
   the ANSI spec is scary, dark, and deep.. -- WHN)

@@ -217,14 +194,13 @@ WORKAROUND:
 
 46:
   type safety errors reported by Peter Van Eynde July 25, 2000:
 
 46:
   type safety errors reported by Peter Van Eynde July 25, 2000:

-       c: (COERCE 'AND 'FUNCTION) returns something related to
-          (MACRO-FUNCTION 'AND), but ANSI says it should raise an error.

        k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is 
           not a binary input stream, but instead cheerfully reads from
           character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc").
 
 60:
   The debugger LIST-LOCATIONS command doesn't work properly.
        k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is 
           not a binary input stream, but instead cheerfully reads from
           character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc").
 
 60:
   The debugger LIST-LOCATIONS command doesn't work properly.

+  (How should it work properly?)

 
 61:
   Compiling and loading
 
 61:
   Compiling and loading

@@ -344,18 +320,29 @@ WORKAROUND:
   so the compiler doesn't compile the type test into code, but
   instead just saves the type in a lexical closure and interprets it
   at runtime.
   so the compiler doesn't compile the type test into code, but
   instead just saves the type in a lexical closure and interprets it
   at runtime.

-    A proper solution involves deciding whether it's really worth
-  saving space by implementing structure slot accessors as closures.
-  (If it's not worth it, the problem vanishes automatically. If it
-  is worth it, there are hacks we could use to force type tests to
-  be compiled anyway, and even shared. E.g. we could implement
-  an EQUAL hash table mapping from types to compiled type tests, 
-  and save the appropriate compiled type test as part of each lexical
-  closure; or we could make the lexical closures be placeholders
-  which overwrite their old definition as a lexical closure with
-  a new compiled definition the first time that they're called.)
-    As a workaround for the problem, #'(SETF FOO) expressions can
-  be replaced with (EFFICIENT-SETF-FUNCTION FOO), where
+    To exercise the problem, compile and load
+      (cl:in-package :cl-user)
+      (defstruct foo
+        (bar (error "missing") :type bar))
+      (defvar *foo*)
+      (defun wastrel1 (x)
+        (loop (setf (foo-bar *foo*) x)))
+      (defstruct bar)
+      (defvar *bar* (make-bar))
+      (defvar *foo* (make-foo :bar *bar*))
+      (defvar *setf-foo-bar* #'(setf foo-bar))
+      (defun wastrel2 (x)
+        (loop (funcall *setf-foo-bar* x *foo*)))
+  then run (WASTREL1 *BAR*) or (WASTREL2 *BAR*), hit Ctrl-C, and
+  use BACKTRACE, to see it's spending all essentially all its time
+  in %TYPEP and VALUES-SPECIFIER-TYPE and so forth.
+    One possible solution would be simply to give up on 
+  representing structure slot accessors as functions, and represent
+  them as macroexpansions instead. This can be inconvenient for users,
+  but it's not clear that it's worse than trying to help by expanding
+  into a horribly inefficient implementation.
+    As a workaround for the problem, #'(SETF FOO) expressions
+  can be replaced with (EFFICIENT-SETF-FUNCTION FOO), where

 (defmacro efficient-setf-function (place-function-name)
   (or #+sbcl (and (sb-int:info :function :accessor-for place-function-name)
                  ;; a workaround for the problem, encouraging the
 (defmacro efficient-setf-function (place-function-name)
   (or #+sbcl (and (sb-int:info :function :accessor-for place-function-name)
                  ;; a workaround for the problem, encouraging the

@@ -562,41 +549,6 @@ WORKAROUND:
 
   See also bugs #45.c and #183
 
 
   See also bugs #45.c and #183
 

-148:
-  In sbcl-0.7.1.3 on x86, COMPILE-FILE on the file
-    (in-package :cl-user)
-    (defvar *thing*)
-    (defvar *zoom*)
-    (defstruct foo bar bletch)
-    (defun %zeep ()
-      (labels ((kidify1 (kid)
-                )
-               (kid-frob (kid)
-                 (if *thing*
-                    (setf sweptm
-                          (m+ (frobnicate kid)
-                                    sweptm))
-                   (kidify1 kid))))
-      (declare (inline kid-frob))
-      (map nil
-          #'kid-frob
-          (the simple-vector (foo-bar perd)))))
-  fails with
-    debugger invoked on condition of type TYPE-ERROR:
-      The value NIL is not of type SB-C::NODE.
-  The location of this failure has moved around as various related
-  issues were cleaned up. As of sbcl-0.7.1.9, it occurs in
-  NODE-BLOCK called by LAMBDA-COMPONENT called by IR2-CONVERT-CLOSURE.
-
-  (Python LET-converts KIDIFY1 into KID-FROB, then tries to inline
-  expand KID-FROB into %ZEEP. Having partially done it, it sees a call
-  of KIDIFY1, which already does not exist. So it gives up on
-  expansion, leaving garbage consisting of infinished blocks of the
-  partially converted function.)
-
-  (due to reordering of the compiler this example is compiled
-  successfully by 0.7.14, but the bug probably remains)
-

 162:
   (reported by Robert E. Brown 2002-04-16) 
   When a function is called with too few arguments, causing the
 162:
   (reported by Robert E. Brown 2002-04-16) 
   When a function is called with too few arguments, causing the

@@ -692,6 +644,15 @@ WORKAROUND:
                (print (incf start 22))
                (print (incf start 26))))))
 
                (print (incf start 22))
                (print (incf start 26))))))
 

+  This example could be solved with clever enough constraint
+  propagation or with SSA, but consider
+
+    (let ((x 0))
+      (loop (incf x 2)))
+
+  The careful type of X is {2k} :-(. Is it really important to be
+  able to work with unions of many intervals?
+

 190: "PPC/Linux pipe? buffer? bug"
   In sbcl-0.7.6, the run-program.test.sh test script sometimes hangs
   on the PPC/Linux platform, waiting for a zombie env process.  This
 190: "PPC/Linux pipe? buffer? bug"
   In sbcl-0.7.6, the run-program.test.sh test script sometimes hangs
   on the PPC/Linux platform, waiting for a zombie env process.  This

@@ -720,7 +681,6 @@ WORKAROUND:
   c. the examples in CLHS 7.6.5.1 (regarding generic function lambda
      lists and &KEY arguments) do not signal errors when they should.
 
   c. the examples in CLHS 7.6.5.1 (regarding generic function lambda
      lists and &KEY arguments) do not signal errors when they should.
 

-

 201: "Incautious type inference from compound types"
   a. (reported by APD sbcl-devel 2002-09-17)
     (DEFUN FOO (X)
 201: "Incautious type inference from compound types"
   a. (reported by APD sbcl-devel 2002-09-17)
     (DEFUN FOO (X)

@@ -1046,6 +1006,31 @@ WORKAROUND:
 257:
   Complex array type does not have corresponding type specifier.
 
 257:
   Complex array type does not have corresponding type specifier.
 

+  This is a problem because the compiler emits optimization notes when
+  you use a non-simple array, and without a type specifier for hairy
+  array types, there's no good way to tell it you're doing it
+  intentionally so that it should shut up and just compile the code.
+
+  Another problem is confusing error message "asserted type ARRAY
+  conflicts with derived type (VALUES SIMPLE-VECTOR &OPTIONAL)" during
+  compiling (LAMBDA (V) (VALUES (SVREF V 0) (VECTOR-POP V))).
+
+  The last problem is that when type assertions are converted to type
+  checks, types are represented with type specifiers, so we could lose
+  complex attribute. (Now this is probably not important, because
+  currently checks for complex arrays seem to be performed by
+  callees.)
+
+258:
+  (fixed in 0.8.1.3)
+
+259:
+  (compile nil '(lambda () (aref (make-array 0) 0))) compiles without
+  warning.  Analogous cases with the index and length being equal and
+  greater than 0 are warned for; the problem here seems to be that the
+  type required for an array reference of this type is (INTEGER 0 (0))
+  which is canonicalized to NIL.
+

 DEFUNCT CATEGORIES OF BUGS
   IR1-#:
     These labels were used for bugs related to the old IR1 interpreter.
 DEFUNCT CATEGORIES OF BUGS
   IR1-#:
     These labels were used for bugs related to the old IR1 interpreter.