X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=08fea2076a380da5cfbe0a6ad535ad0613211333;hb=40bf78b47ea89b15698adb9c550efa4cbacafeb7;hp=fb9a754ad9eeaf7aa110b81ae2aa43446f5c7751;hpb=223ac55abed63769d0a3d5831b499d0ee9ee6462;p=sbcl.git diff --git a/BUGS b/BUGS index fb9a754..08fea20 100644 --- a/BUGS +++ b/BUGS @@ -42,7 +42,8 @@ KNOWN BUGS OF NO SPECIAL CLASS: program, even if you know or guess enough about the internals of SBCL to wager that this (undefined in ANSI) operation would be safe. -3: +3: "type checking of structure slots" + a: ANSI specifies that a type mismatch in a structure slot initialization value should not cause a warning. WORKAROUND: @@ -78,6 +79,28 @@ WORKAROUND: Such code should compile without complaint and work correctly either on SBCL or on any other completely compliant Common Lisp system. + b: &AUX argument in a boa-constructor without a default value means + "do not initilize this slot" and does not cause type error. But + 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. + + 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. + 6: bogus warnings about undefined functions for magic functions like SB!C::%%DEFUN and SB!C::%DEFCONSTANT when cross-compiling files @@ -283,10 +306,6 @@ WORKAROUND: need to document exactly what metaobject protocol specification we're following -- the current code is just inherited from PCL.) -54: - The implementation of #'+ returns its single argument without - type checking, e.g. (+ "illegal") => "illegal". - 60: The debugger LIST-LOCATIONS command doesn't work properly. @@ -297,40 +316,6 @@ WORKAROUND: then requesting a BACKTRACE at the debugger prompt gives no information about where in the user program the problem occurred. -62: - The compiler is supposed to do type inference well enough that - the declaration in - (TYPECASE X - ((SIMPLE-ARRAY SINGLE-FLOAT) - (LOCALLY - (DECLARE (TYPE (SIMPLE-ARRAY SINGLE-FLOAT) X)) - ..)) - ..) - is redundant. However, as reported by Juan Jose Garcia Ripoll for - CMU CL, it sometimes doesn't. Adding declarations is a pretty good - workaround for the problem for now, but can't be done by the TYPECASE - macros themselves, since it's too hard for the macro to detect - assignments to the variable within the clause. - Note: The compiler *is* smart enough to do the type inference in - many cases. This case, derived from a couple of MACROEXPAND-1 - calls on Ripoll's original test case, - (DEFUN NEGMAT (A) - (DECLARE (OPTIMIZE SPEED (SAFETY 0))) - (COND ((TYPEP A '(SIMPLE-ARRAY SINGLE-FLOAT)) NIL - (LET ((LENGTH (ARRAY-TOTAL-SIZE A))) - (LET ((I 0) (G2554 LENGTH)) - (DECLARE (TYPE REAL G2554) (TYPE REAL I)) - (TAGBODY - SB-LOOP::NEXT-LOOP - (WHEN (>= I G2554) (GO SB-LOOP::END-LOOP)) - (SETF (ROW-MAJOR-AREF A I) (- (ROW-MAJOR-AREF A I))) - (GO SB-LOOP::NEXT-LOOP) - SB-LOOP::END-LOOP)))))) - demonstrates the problem; but the problem goes away if the TAGBODY - and GO forms are removed (leaving the SETF in ordinary, non-looping - code), or if the TAGBODY and GO forms are retained, but the - assigned value becomes 0.0 instead of (- (ROW-MAJOR-AREF A I)). - 63: Paul Werkowski wrote on cmucl-imp@cons.org 2000-11-15 I am looking into this problem that showed up on the cmucl-help @@ -382,6 +367,9 @@ WORKAROUND: LOAD-FOREIGN, and (2) hunt for any other code which uses temporary files and make it share the same new safe logic. + (partially alleviated in sbcl-0.7.9.32 by a fix by Matthew Danish to + make the temporary filename less easily guessable) + 82: Functions are assigned names based on the context in which they're defined. This is less than ideal for the functions which are @@ -503,22 +491,6 @@ WORKAROUND: time trying to GC afterwards. Surely there's some more economical way to implement (ROOM T). -115: - reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs - collection: - (in-package :cl-user) - ;;; The following invokes a compiler error. - (declaim (optimize (speed 2) (debug 3))) - (defun tst () - (flet ((m1 () - (unwind-protect nil))) - (if (catch nil) - (m1) - (m1)))) - The error message in sbcl-0.6.12.42 is - internal error, failed AVER: - "(COMMON-LISP:EQ (SB!C::TN-ENVIRONMENT SB!C:TN) SB!C::TN-ENV)" - 117: When the compiler inline expands functions, it may be that different kinds of return values are generated from different code branches. @@ -633,12 +605,6 @@ WORKAROUND: Evidently Python thinks of the lambda as a code transformation so much that it forgets that it's also an object. -127: - The DEFSTRUCT section of the ANSI spec, in the :CONC-NAME section, - specifies a precedence rule for name collisions between slot accessors of - structure classes related by inheritance. As of 0.7.0, SBCL still - doesn't follow it. - 135: Ideally, uninterning a symbol would allow it, and its associated FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However, @@ -649,22 +615,16 @@ WORKAROUND: forever, even when it is uninterned and all other references to it are lost. -136: - (reported by Arnaud Rouanet on cmucl-imp 2001-12-18) - (defmethod foo ((x integer)) - x) - (defmethod foo :around ((x integer)) - (let ((x (1+ x))) - (call-next-method))) - Now (FOO 3) should return 3, but instead it returns 4. - -141: - Pretty-printing nested backquotes doesn't work right, as - reported by Alexey Dejneka sbcl-devel 2002-01-13: - * '``(FOO ,@',@S) - ``(FOO SB-IMPL::BACKQ-COMMA-AT S) - * (lisp-implementation-version) - "0.pre7.129" +141: "pretty printing and backquote" + a. + * '``(FOO ,@',@S) + ``(FOO SB-IMPL::BACKQ-COMMA-AT S) + + b. + * (write '`(, .ala.) :readably t :pretty t) + `(,.ALA.) + + (note the space between the comma and the point) 143: (reported by Jesse Bouwman 2001-10-24 through the unfortunately @@ -756,11 +716,6 @@ WORKAROUND: expansion, leaving garbage consisting of infinished blocks of the partially converted function.) -157: - Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and - UPGRADED-COMPLEX-PART-TYPE should have an optional environment argument. - (reported by Alexey Dejneka sbcl-devel 2002-04-12) - 162: (reported by Robert E. Brown 2002-04-16) When a function is called with too few arguments, causing the @@ -781,31 +736,6 @@ WORKAROUND: isn't too surprising since there are many differences in stack implementation and GC conservatism between the X86 and other ports.) -166: - Compiling - (in-package :cl-user) - (defstruct uustk) - (defmethod permanentize ((uustk uustk)) - (flet ((frob (hash-table test-for-deletion) - ) - (obj-entry.stale? (oe) - (destructuring-bind (key . datum) oe - (declare (type simple-vector key)) - (deny0 (void? datum)) - (some #'stale? key)))) - (declare (inline frob obj-entry.stale?)) - (frob (uustk.args-hash->obj-alist uustk) - #'obj-entry.stale?) - (frob (uustk.hash->memoized-objs-list uustk) - #'objs.stale?)) - (call-next-method)) - in sbcl-0.7.3.11 causes an assertion failure, - failed AVER: - "(NOT -(AND (NULL (BLOCK-SUCC B)) - (NOT (BLOCK-DELETE-P B)) - (NOT (EQ B (COMPONENT-HEAD #)))))" - 167: In sbcl-0.7.3.11, compiling the (illegal) code (in-package :cl-user) @@ -820,14 +750,6 @@ WORKAROUND: macro is unhappy with the illegal syntax in the method body, and is giving an unclear error message. -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 @@ -843,19 +765,6 @@ WORKAROUND: 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. -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))) - - (since 0.7.8.9 it does not signal an error; see also bug 199) - 183: "IEEE floating point issues" Even where floating point handling is being dealt with relatively well (as of sbcl-0.7.5, on sparc/sunos and alpha; see bug #146), the @@ -1018,24 +927,10 @@ WORKAROUND: (see bug 203) -193: "unhelpful CLOS error reporting when the primary method is missing" - In sbcl-0.7.7, when - (defmethod foo :before ((x t)) (print x)) - is the only method defined on FOO, the error reporting when e.g. - (foo 12) - is relatively unhelpful: - There is no primary method for the generic function - #. - with the offending argument nowhere visible in the backtrace. This - continues even if there *are* primary methods, just not for the - specified arg type, e.g. - (defmethod foo ((x character)) (print x)) - (defmethod foo ((x string)) (print x)) - (defmethod foo ((x pathname)) ...) - In that case it could be very helpful to know what argument value is - falling through the cracks of the defined primary methods, but the - error message stays the same (even BACKTRACE doesn't tell you what the - bad argument value is). + c. (defun foo (x y) + (locally (declare (type fixnum x y)) + (+ x (* 2 y)))) + (foo 1.1 2) => 5.1 194: "no error from (THE REAL '(1 2 3)) in some cases" fixed parts: @@ -1044,11 +939,11 @@ WORKAROUND: returns (1 2 3) instead of signalling an error. This was fixed by APD's "more strict type checking patch", but although the fixed code (in sbcl-0.7.7.19) works (signals TYPE-ERROR) interactively, - it's difficult to write a regression test for it, because + it's difficult to write a regression test for it, because (IGNORE-ERRORS (MULTIPLE-VALUE-PROG1 (PROGN (THE REAL '(1 2 3))))) still returns (1 2 3). - still-broken parts: - b. (IGNORE-ERRORS (MULTIPLE-VALUE-PROG1 (PROGN (THE REAL '(1 2 3))))) + still-broken parts: + b. (IGNORE-ERRORS (MULTIPLE-VALUE-PROG1 (PROGN (THE REAL '(1 2 3))))) returns (1 2 3). (As above, this shows up when writing regression tests for fixed-ness of part a.) c. Also in sbcl-0.7.7.9, (IGNORE-ERRORS (THE REAL '(1 2 3))) => (1 2 3). @@ -1073,27 +968,9 @@ WORKAROUND: inaccurate transformations. * Alexey Dejneka pointed out that (IGNORE-ERRORS (IDENTITY (THE REAL '(1 2 3)))) - works as it should. Also + and (IGNORE-ERRORS (VALUES (THE REAL '(1 2 3)))) - works as it should. Perhaps this is another case of VALUES type - intersections behaving in non-useful ways? - -199: "hairy FUNCTION types confuse the compiler" - (reported by APD sbcl-devel 2002-09-15) - (DEFUN MUR (F) - (EQ NIL (FUNCALL F))) - - (DEFUN FOO (F X) - (DECLARE (TYPE (AND FUNCTION (SATISFIES MUR)) F)) - (FUNCALL F X)) - - fails to compile, printing - failed AVER: - "(AND (EQ (IR2-CONTINUATION-PRIMITIVE-TYPE 2CONT) FUNCTION-PTYPE) (EQ CHECK T))" - - APD further reports that this bug is not present in CMUCL. - - (this case was fixed in 0.7.8.9; see also bug 178) + work as they should. 201: "Incautious type inference from compound CONS types" (reported by APD sbcl-devel 2002-09-17) @@ -1115,7 +992,7 @@ WORKAROUND: (progn (the real (list 1)) t) This situation may appear during optimizing away degenerate cases of - certain functions: see bugs 54, 192b. + certain functions: see bug 192b. 205: "environment issues in cross compiler" (These bugs have no impact on user code, but should be fixed or @@ -1124,6 +1001,8 @@ WORKAROUND: lexical environment. b. The body of (EVAL-WHEN (:COMPILE-TOPLEVEL) ...) is evaluated in the null lexical environment. + c. The cross-compiler cannot inline functions defined in a non-null + lexical environment. 206: ":SB-FLUID feature broken" (reported by Antonio Martinez-Shotton sbcl-devel 2002-10-07) @@ -1148,7 +1027,7 @@ WORKAROUND: 29-bit pseudorandom numbers? 208: "package confusion in PCL handling of structure slot handlers" - In sbcl-0.7.8 compiling and loading + In sbcl-0.7.8 compiling and loading (in-package :cl) (defstruct foo (slot (error "missing")) :type list :read-only t) (defmethod print-object ((foo foo) stream) (print nil stream)) @@ -1168,7 +1047,7 @@ WORKAROUND: ; in: LAMBDA NIL ; (FOO :Y 1 :Y 2) - ; + ; ; caught STYLE-WARNING: ; The variable #:G15 is defined but never used. @@ -1178,14 +1057,14 @@ WORKAROUND: given an error instead (ANSI 17.1.1 allows this behaviour on the part of the implementation, as conforming code cannot give non-proper sequences to these functions. MAP also has this problem (and - solution), though arguably the convenience of being able to do - (MAP 'LIST '+ FOO '#1=(1 . #1#)) + solution), though arguably the convenience of being able to do + (MAP 'LIST '+ FOO '#1=(1 . #1#)) might be classed as more important (though signalling an error when all of the arguments are circular is probably desireable). 213: "Sequence functions and type checking" a. MAKE-SEQUENCE, COERCE, MERGE and CONCATENATE cannot deal with - various complicated, though recognizeable, CONS types [e.g. + various complicated, though recognizeable, CONS types [e.g. (CONS * (CONS * NULL)) which according to ANSI should be recognized] (and, in SAFETY 3 code, should return a list of LENGTH 2 or signal an error) @@ -1198,7 +1077,7 @@ WORKAROUND: (CONS INTEGER *) whether or not the return value is of this type. This is probably permitted by ANSI (see "Exceptional Situations" under - ANSI MAKE-SEQUENCE), but the DERIVE-TYPE mechanism does not + ANSI MAKE-SEQUENCE), but the DERIVE-TYPE mechanism does not know about this escape clause, so code of the form (INTEGERP (CAR (MAKE-SEQUENCE '(CONS INTEGER *) 2))) can erroneously return T. @@ -1273,22 +1152,136 @@ WORKAROUND: (defun test (x y) (the (values integer) (truncate x y))) (test 10 4) => 2 -219: "DEFINE-COMPILER-MACRO in non-toplevel contexts evaluated at compile-time" - In sbcl-0.7.9: - - * (defun foo (x) - (when x - (define-compiler-macro bar (&whole whole) - (declare (ignore whole)) - (print "expanding compiler macro") - 1))) - FOO - * (defun baz (x) (bar)) - [ ... ] - "expanding compiler macro" - BAZ - * (baz t) - 1 +220: + Sbcl 0.7.9 fails to compile + + (multiple-value-call #'list + (the integer (helper)) + nil) + + Type check for INTEGER, the result of which serves as the first + argument of M-V-C, is inserted after evaluation of NIL. So arguments + of M-V-C are pushed in the wrong order. As a temporary workaround + type checking was disabled for M-V-Cs in 0.7.9.13. A better solution + would be to put the check between evaluation of arguments, but it + could be tricky to check result types of PROG1, IF etc. + +229: + (subtypep 'function '(function)) => nil, t. + +231: "SETQ does not correctly check the type of a variable being set" + b. + (defun foo (x z) + (declare (type integer x)) + (locally (declare (type (real 1) x)) + (setq x z)) + (list x z)) + (foo 0 0) => (0 0). + + (fixed in 0.7.12.8) + +233: bugs in constraint propagation + a. + (defun foo (x) + (declare (optimize (speed 2) (safety 3))) + (let ((y 0d0)) + (values + (the double-float x) + (setq y (+ x 1d0)) + (setq x 3d0) + (quux y (+ y 2d0) (* y 3d0))))) + (foo 4) => segmentation violation + + (see usage of CONTINUATION-ASSERTED-TYPE in USE-RESULT-CONSTRAINTS) + (see also bug 236) + + b. + (declaim (optimize (speed 2) (safety 3))) + (defun foo (x y) + (if (typep (prog1 x (setq x y)) 'double-float) + (+ x 1d0) + (+ x 2))) + (foo 1d0 5) => segmentation violation + +235: "type system and inline expansion" + a. + (declaim (ftype (function (cons) number) acc)) + (declaim (inline acc)) + (defun acc (c) + (the number (car c))) + + (defun foo (x y) + (values (locally (declare (optimize (safety 0))) + (acc x)) + (locally (declare (optimize (safety 3))) + (acc y)))) + + (foo '(nil) '(t)) => NIL, T. + + b. (reported by brown on #lisp 2003-01-21) + + (defun find-it (x) + (declare (optimize (speed 3) (safety 0))) + (declare (notinline mapcar)) + (let ((z (mapcar #'car x))) + (find 'foobar z))) + + Without (DECLARE (NOTINLINE MAPCAR)), Python cannot derive that Z is + LIST. + +236: "THE semantics is broken" + + (defun foo (a f) + (declare (optimize (speed 2) (safety 0))) + (+ 1d0 + (the double-float + (multiple-value-prog1 + (svref a 0) + (unless f (return-from foo 0)))))) + + (foo #(4) nil) => SEGV + + VOP selection thinks that in unsafe code result type assertions + should be valid immediately. (See also bug 233a.) + + The similar problem exists for TRULY-THE. + +237: "Environment arguments to type functions" + a. Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and + UPGRADED-COMPLEX-PART-TYPE now have an optional environment + argument, but they ignore it completely. This is almost + certainly not correct. + b. Also, the compiler's optimizers for TYPEP have not been informed + about the new argument; consequently, they will not transform + calls of the form (TYPEP 1 'INTEGER NIL), even though this is + just as optimizeable as (TYPEP 1 'INTEGER). + +238: "REPL compiler overenthusiasm for CLOS code" + From the REPL, + * (defclass foo () ()) + * (defmethod bar ((x foo) (foo foo)) (call-next-method)) + causes approximately 100 lines of code deletion notes. Some + discussion on this issue happened under the title 'Three "interesting" + bugs in PCL', resulting in a fix for this oververbosity from the + compiler proper; however, the problem persists in the interactor + because the notion of original source is not preserved: for the + compiler, the original source of the above expression is (DEFMETHOD + BAR ((X FOO) (FOO FOO)) (CALL-NEXT-METHOD)), while by the time the + compiler gets its hands on the code needing compilation from the REPL, + it has been macroexpanded several times. + +241: + "DEFCLASS mysteriously remembers uninterned accessor names." + (from tonyms on #lisp IRC 2003-02-25) + In sbcl-0.7.12.55, typing + (defclass foo () ((bar :accessor foo-bar))) + (profile foo-bar) + (unintern 'foo-bar) + (defclass foo () ((bar :accessor foo-bar))) + gives the error message + "#:FOO-BAR already names an ordinary function or a macro." + So it's somehow checking the uninterned old accessor name instead + of the new requested accessor name, which seems broken to me (WHN). DEFUNCT CATEGORIES OF BUGS IR1-#: