X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;ds=sidebyside;f=BUGS;h=48ca825687a223c01fbd848d1df0b7acb5d1dad6;hb=2d3009d3aacab5cb466fc5b85096603ae5f6ace4;hp=b6981d21645cc4d8bf85687033f1d8ec5f7181aa;hpb=b1b85bbf17f686a0787304a04cf0e01e8216d038;p=sbcl.git

diff --git a/BUGS b/BUGS
index b6981d2..48ca825 100644
--- a/BUGS
+++ b/BUGS
@@ -861,26 +861,12 @@ WORKAROUND:
   b. The same for CSUBTYPEP.
 
 262: "yet another bug in inline expansion of local functions"
-  Compiler fails on
-
-    (defun foo (x y)
-      (declare (integer x y))
-      (+ (block nil
-            (flet ((xyz (u)
-                     (declare (integer u))
-                     (if (> (1+ (the unsigned-byte u)) 0)
-                         (+ 1 u)
-                         (return (+ 38 (cos (/ u 78)))))))
-              (declare (inline xyz))
-              (return-from foo
-                (* (funcall (eval #'xyz) x)
-                   (if (> x 30)
-                       (funcall (if (> x 5) #'xyz #'identity)
-                                (+ x 13))
-                       38)))))
-         (sin (* x y))))
-
-  Urgh... It's time to write IR1-copier.
+  During inline expansion of a local function Python can try to
+  reference optimized away objects (functions, variables, CTRANs from
+  tags and blocks), which later may lead to problems. Some of the
+  cases are worked around by forbidding expansion in such cases, but
+  the better way would be to reimplement inline expansion by copying
+  IR1 structures.
 
 266:
   David Lichteblau provided (sbcl-devel 2003-06-01) a patch to fix
@@ -1101,14 +1087,6 @@ WORKAROUND:
   gives the error
     failed AVER: "(NOT (AND (NOT EQUALP) CERTAINP))"
 
-302: Undefined type messes up DATA-VECTOR-REF expansion.
-  Compiling this file
-    (defun dis (s ei x y)
-      (declare (type (simple-array function (2)) s) (type ei ei))
-      (funcall (aref s ei) x y))
-  on sbcl-0.8.7.36/X86/Linux causes a BUG to be signalled:
-    full call to SB-KERNEL:DATA-VECTOR-REF
-
 303: "nonlinear LVARs" (aka MISC.293)
     (defun buu (x)
       (multiple-value-call #'list
@@ -1153,23 +1131,6 @@ WORKAROUND:
                collect `(array ,(sb-vm:saetp-specifier x)))))
     => NIL, T (when it should be T, T)
 
-308: "Characters without names"
-    (reported by Bruno Haible sbcl-devel "character names are missing"
-    2004-04-19)
-  (graphic-char-p (code-char 255))
-  => NIL
-  (char-name (code-char 255))
-  => NIL
-
-  SBCL is unsure of what to do about characters with codes in the
-  range 128-255.  Currently they are treated as non-graphic, but don't
-  have names, which is not compliant with the standard.  Various fixes
-  are possible, such as
-  * giving them names such as NON-ASCII-128;
-  * reducing CHAR-CODE-LIMIT to 127 (almost certainly unpopular);
-  * making the characters graphic (makes a certain amount of sense);
-  * biting the bullet and implementing Unicode (probably quite hard).
-
 309: "Dubious values for implementation limits"
     (reported by Bruno Haible sbcl-devel "Incorrect value of
     multiple-values-limit" 2004-04-19)
@@ -1618,40 +1579,15 @@ WORKAROUND:
   pprinter and only truncated at output?  (So that indenting by 1/2
   then 3/2 would indent by two spaces, not one?)
 
-350: heap overflow when printing bignums
-  (reported by Bruno Haible 2004-10-08)
-  In sbcl-0.8.15.18,
-    * (DEFPARAMETER *BIG* (ASH 1 1000000))
-    *BIG*
-    * (PRINT *BIG*)
-    Argh! gc_find_freeish_pages failed (restart_page), nbytes=110152.
-  It should be straightforward to push the heap overflow threshold
-  up to much larger bignums; Paul Dietz pointed out it would help to 
-  use a bignum-printing algorithm which bisected the printed number,
-  rather than stripping off digits one by one, and CSR suggested using
-  iteration rather than recursion to encourage intermediate results
-  to be GCed.
-
-351: suboptimal error handling/reporting when compiling (PUSH (LET ...)) 
-  In sbcl-0.8.15.18,
-    * (defvar *b*)
-    *B*
-    * (defun oops ()
-        (push *b*
-              (let ((b *b*))
-                (aref b 1))))
-  causes the compiler to die with a TYPE-ERROR in SB-C::EXTRACT-LET-VARS,
-    The value #:G4 is not of type LIST.
-  Since the (LET ...) expression is being misused in PUSH as a 
-  SETFable place, it would be more helpful to fail as in 
-    * (defun oops2 () (setf (let ((b *b*)) (aref b 1)) *b*))
-  with compilation errors and warnings like 
-    ; in: LAMBDA NIL
-    ;     ((B *B*))
-    ; caught ERROR:
-    ;   illegal function call
-  and
-    ; caught WARNING:
-    ;   The function (SETF LET) is undefined, and its name is reserved 
-    ;   by ANSI CL so that even if it were defined later, the code 
-    ;   doing so would not be portable.
+352: forward-referenced-class trouble
+ reported by Bruno Haible on sbcl-devel
+   (defclass c (a) ())
+   (setf (class-name (find-class 'a)) 'b)
+   (defclass a () (x))
+   (defclass b () (y))
+   (make-instance 'c)
+ Expected: an instance of c, with a slot named x
+ Got: debugger invoked on a SIMPLE-ERROR in thread 78906:
+        While computing the class precedence list of the class named C.
+        The class named B is a forward referenced class.
+        The class named B is a direct superclass of the class named C.