X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=cd8dc4087a117a693e528bd18568330409d14cab;hb=69cd16d7335a7f66985752b84f78d18e45f9783e;hp=96b71400978402196096ca9e16bf028659932822;hpb=9cbb7f9b3a418314ffcd8f2cb0448278d2b6f812;p=sbcl.git diff --git a/BUGS b/BUGS index 96b7140..cd8dc40 100644 --- a/BUGS +++ b/BUGS @@ -142,15 +142,6 @@ WORKAROUND: DTC's recommended workaround from the mailing list 3 Mar 2000: (setf (pcl::find-class 'ccc1) (pcl::find-class 'ccc)) -22: - The ANSI spec, in section "22.3.5.2 Tilde Less-Than-Sign: Logical Block", - says that an error is signalled if ~W, ~_, ~<...~:>, ~I, or ~:T is used - inside "~<..~>" (without the colon modifier on the closing syntax). - However, SBCL doesn't do this: - * (FORMAT T "~" 12) - munge12egnum - NIL - 27: Sometimes (SB-EXT:QUIT) fails with Argh! maximum interrupt nesting depth (4096) exceeded, exiting @@ -269,9 +260,6 @@ WORKAROUND: MERGE also have the same problem. c: (COERCE 'AND 'FUNCTION) returns something related to (MACRO-FUNCTION 'AND), but ANSI says it should raise an error. - f: (FLOAT-RADIX 2/3) should signal an error instead of - returning 2. - g: (LOAD "*.lsp") should signal FILE-ERROR. h: (MAKE-CONCATENATED-STREAM (MAKE-STRING-OUTPUT-STREAM)) should signal TYPE-ERROR. i: MAKE-TWO-WAY-STREAM doesn't check that its arguments can @@ -279,10 +267,6 @@ WORKAROUND: TYPE-ERROR when handed e.g. the results of MAKE-STRING-INPUT-STREAM or MAKE-STRING-OUTPUT-STREAM in the inappropriate positions, but doesn't. - j: (PARSE-NAMESTRING (COERCE (LIST #\f #\o #\o (CODE-CHAR 0) #\4 #\8) - (QUOTE STRING))) - should probably signal an error instead of making a pathname with - a null byte in it. 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"). @@ -474,14 +458,6 @@ WORKAROUND: crashes SBCL. In general tracing anything which is used in the implementation of TRACE is likely to have the same problem. -68: - As reported by Daniel Solaz on cmucl-help@cons.org 2000-11-23, - SXHASH returns the same value for all non-STRUCTURE-OBJECT instances, - notably including all PCL instances. There's a limit to how much - SXHASH can do to return unique values for instances, but at least - it should probably look at the class name, the way that it does - for STRUCTURE-OBJECTs. - 70: (probably related to bug #65; maybe related to bug #109) The compiler doesn't like &OPTIONAL arguments in LABELS and FLET @@ -503,12 +479,6 @@ WORKAROUND: (SB-C::LAMBDA-TAIL-SET (SB-C::LAMBDA-HOME SB-C::CALLEE))) failed. -71: - (DECLAIM (OPTIMIZE ..)) doesn't work. E.g. even after - (DECLAIM (OPTIMIZE (SPEED 3))), things are still optimized with - the previous SPEED policy. This bug will probably get fixed in - 0.6.9.x in a general cleanup of optimization policy. - 72: (DECLAIM (OPTIMIZE ..)) doesn't work properly inside LOCALLY forms. @@ -667,7 +637,7 @@ WORKAROUND: but SBCL doesn't do this. (Also as reported by AL in the same message, SBCL depended on this nonconforming behavior to build itself, because of the way that **CURRENT-SEGMENT** was implemented. - As of sbcl-0.6.12.x, this dependence on the nonconforming behavior + As of sbcl-0.7.3.x, this dependence on the nonconforming behavior has been fixed, but the nonconforming behavior remains.) 104: @@ -912,9 +882,6 @@ WORKAROUND: 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) - 127: The DEFSTRUCT section of the ANSI spec, in the :CONC-NAME section, specifies a precedence rule for name collisions between slot accessors of @@ -1018,36 +985,6 @@ WORKAROUND: still some functions named "hairy arg processor" and "SB-INT:&MORE processor". -140: - (reported by Alexey Dejneka sbcl-devel 2002-01-03) - - SUBTYPEP does not work well with redefined classes: - --- - * (defclass a () ()) - # - * (defclass b () ()) - # - * (subtypep 'b 'a) - NIL - T - * (defclass b (a) ()) - # - * (subtypep 'b 'a) - T - T - * (defclass b () ()) - # - - ;;; And now... - * (subtypep 'b 'a) - T - T - - This is probably due to underzealous clearing of the type caches; a - brute-force solution in that case would be to make a defclass expand - into something that included a call to SB-KERNEL::CLEAR-TYPE-CACHES, - but there may be a better solution. - 141: Pretty-printing nested backquotes doesn't work right, as reported by Alexey Dejneka sbcl-devel 2002-01-13: @@ -1175,9 +1112,6 @@ WORKAROUND: but it has happened in more complicated cases (which I haven't figured out how to reproduce). -155: - (fixed in sbcl-0.7.2.9) - 156: FUNCTION-LAMBDA-EXPRESSION doesn't work right in 0.7.0 or 0.7.2.9: * (function-lambda-expression #'(lambda (x) x)) @@ -1190,16 +1124,6 @@ WORKAROUND: UPGRADED-COMPLEX-PART-TYPE should have an optional environment argument. (reported by Alexey Dejneka sbcl-devel 2002-04-12) -158: - Compiling the following code causes SBCL 0.7.2 to bug. This only - happens with optimization enabled, and only when the loop variable is - being incremented by more than 1. - (defun foo (array) - (declare (optimize (safety 0) (space 0) (debug 0) (speed 3))) - (loop for i from 0 to 10 by 2 - do (foo (svref array i))) (svref array (1+ i))) - (reported by Eric Marsden sbcl-devel 2002-04-15) - 162: (reported by Robert E. Brown 2002-04-16) When a function is called with too few arguments, causing the @@ -1220,17 +1144,6 @@ WORKAROUND: isn't too surprising since there are many differences in stack implementation and GC conservatism between the X86 and other ports.) -163: - HOST-NAMESTRING on a Unix pathname returns "Unix", which isn't - treated as a valid host by anything else in the system. (Reported by - Erik Naggum on comp.lang.lisp 2002-04-18) - -164: - The type system still can't quite deal with all useful identities; - for instance, as of sbcl-0.7.2.18, the type specifier '(and (real -1 - 7) (real 4 8)) is a HAIRY-TYPE rather than that which would be hoped - for, viz: '(real 4 7). - 165: Array types with element-types of some unknown type are falsely being assumed to be of type (ARRAY T) by the compiler in some cases. The @@ -1291,6 +1204,104 @@ WORKAROUND: macro is unhappy with the illegal syntax in the method body, and is giving an unclear error message. +168: + (reported by Dan Barlow on sbcl-devel 2002-05-10) + In sbcl-0.7.3.12, doing + (defstruct foo bar baz) + (compile nil (lambda (x) (or x (foo-baz x)))) + gives an error + debugger invoked on condition of type SB-INT:BUG: + full call to SB-KERNEL:%INSTANCE-REF + This is probably a bug in SBCL itself. [...] + Since this is a reasonable user error, it shouldn't be reported as + an SBCL bug. + +171: + (reported by Pierre Mai while investigating bug 47): + (DEFCLASS FOO () ((A :SILLY T))) + signals a SIMPLE-ERROR, not a PROGRAM-ERROR. + +172: + sbcl's treatment of at least macro lambda lists is too permissive; + e.g., in sbcl-0.7.3.7: + (defmacro foo (&rest rest bar) `(,bar ,rest)) + (macroexpand '(foo quux zot)) -> (QUUX (QUUX ZOT)) + whereas section 3.4.4 of the CLHS doesn't allow required parameters + to come after the rest argument. + +173: + The compiler sometimes tries to constant-fold expressions before + it checks to see whether they can be reached. This can lead to + bogus warnings about errors in the constant folding, e.g. in code + like + (WHEN X + (WRITE-STRING (> X 0) "+" "0")) + compiled in a context where the compiler can prove that X is NIL, + and the compiler complains that (> X 0) causes a type error because + NIL isn't a valid argument to #'>. Until sbcl-0.7.4.10 or so this + caused a full WARNING, which made the bug really annoying because then + COMPILE and COMPILE-FILE returned FAILURE-P=T for perfectly legal + code. Since then the warning has been downgraded to STYLE-WARNING, + so it's still a bug but at least it's a little less annoying. + +174: + The error message from attempting to use a #\Return format + directive: + (format nil "~^M") ; replace "^M" with a literal #\Return + debugger invoked on condition of type SB-FORMAT::FORMAT-ERROR: + error in format: unknown format directive + ~ + ^ + is not terribly helpful; this is more noticeable than parallel cases + with e.g. #\Backspace because of the differing newline conventions + on various operating systems. (reported by Harald Hanche-Olsen on + cmucl-help 2002-05-31) + +176: + reported by Alexey Dejneka 08 Jun 2002 in sbcl-devel: + Playing with McCLIM, I've received an error "Unbound variable WRAPPER + in SB-PCL::CHECK-WRAPPER-VALIDITY". + (defun check-wrapper-validity (instance) + (let* ((owrapper (wrapper-of instance))) + (if (not (invalid-wrapper-p owrapper)) + owrapper + (let* ((state (wrapper-state wrapper)) ; !!! + ... + I've tried to replace it with OWRAPPER, but now OBSOLETE-INSTANCE-TRAP + breaks with "NIL is not of type SB-KERNEL:LAYOUT". + SBCL 0.7.4.13. + partial fix: The undefined variable WRAPPER resulted from an error + in recent refactoring, as can be seen by comparing to the code in e.g. + sbcl-0.7.2. Replacing WRAPPER with OWRAPPER (done by WHN in sbcl-0.7.4.22) + should bring the code back to its behavior as of sbcl-0.7.2, but + that still leaves the OBSOLETE-INSTANCE-TRAP bug. An example of + input which triggers that bug is + (dotimes (i 20) + (let ((lastname (intern (format nil "C~D" (1- i)))) + (name (intern (format nil "C~D" i)))) + (eval `(defclass ,name + (,@(if (= i 0) nil (list lastname))) + ())) + (eval `(defmethod initialize-instance :after ((x ,name) &rest any) + (declare (ignore any)))))) + (defclass b () ()) + (defclass c0 (b) ()) + (make-instance 'c19) + +178: "AVER failure compiling confused THEs in FUNCALL" + In sbcl-0.7.4.24, compiling + (defun bug178 (x) + (funcall (the function (the standard-object x)))) + gives + failed AVER: + "(AND (EQ (IR2-CONTINUATION-PRIMITIVE-TYPE 2CONT) FUNCTION-PTYPE) (EQ CHECK T))" + This variant compiles OK, though: + (defun bug178alternative (x) + (funcall (the nil x))) + +179: + (fixed in sbcl-0.7.4.28) + DEFUNCT CATEGORIES OF BUGS IR1-#: These labels were used for bugs related to the old IR1 interpreter.