X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=de90432424d34e54a95b3985faea9607e00cff95;hb=3c76429562383ac91cec4880b7b86234362e1ed4;hp=6fd716f2b62cf82f60f7defccab8c493f6867edd;hpb=9347abeb5f42dc83d372c19b14e86204a6a588dd;p=sbcl.git diff --git a/BUGS b/BUGS index 6fd716f..de90432 100644 --- a/BUGS +++ b/BUGS @@ -183,7 +183,7 @@ WORKAROUND: then executing (FOO 1.5) will cause the INTEGERP case to be selected, giving bogus output a la - exactly 1.33.. + exactly 2.5 This violates the "declarations are assertions" principle. According to the ANSI spec, in the section "System Class FUNCTION", this is a case of "lying to the compiler", but the lying is done @@ -276,13 +276,6 @@ WORKAROUND: 47: DEFCLASS bugs reported by Peter Van Eynde July 25, 2000: - a: (DEFCLASS FOO () (A B A)) should signal a PROGRAM-ERROR, and - doesn't. - b: (DEFCLASS FOO () (A B A) (:DEFAULT-INITARGS X A X B)) should - signal a PROGRAM-ERROR, and doesn't. - c: (DEFCLASS FOO07 NIL ((A :ALLOCATION :CLASS :ALLOCATION :CLASS))), - and other DEFCLASS forms with duplicate specifications in their - slots, should signal a PROGRAM-ERROR, and doesn't. d: (DEFGENERIC IF (X)) should signal a PROGRAM-ERROR, but instead causes a COMPILER-ERROR. @@ -303,9 +296,6 @@ WORKAROUND: (DEFGENERIC FOO03 (X)) (ADD-METHOD (FUNCTION FOO03) M))) should give an error, but SBCL allows it. - b: READ should probably return READER-ERROR, not the bare - arithmetic error, when input a la "1/0" or "1e1000" causes - an arithmetic error. 52: It has been reported (e.g. by Peter Van Eynde) that there are @@ -564,43 +554,6 @@ WORKAROUND: time trying to GC afterwards. Surely there's some more economical way to implement (ROOM T). -110: - reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs - collection: - ;;; The compiler is flushing the argument type test, and the default - ;;; case in the cond, so that calling with say a fixnum 0 causes a - ;;; SIGBUS. - (declaim (optimize (safety 2) (speed 3))) - (defun tst (x) - (declare (type (or string stream) x)) - (cond ((typep x 'string) 'string) - ((typep x 'stream) 'stream) - (t - 'none))) - The symptom in sbcl-0.6.12.42 on OpenBSD is actually (TST 0)=>STREAM - (not the SIGBUS reported in the comment) but that's broken too; - type declarations are supposed to be treated as assertions unless - SAFETY 0, so we should be getting a TYPE-ERROR. - -113: - reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs - collection: - (in-package :cl-user) - ;;; From: David Gadbois - ;;; - ;;; Logical pathnames aren't externalizable. - ;;; Test case: - (let ((tempfile "/tmp/test.lisp")) - (setf (logical-pathname-translations "XXX") - '(("XXX:**;*.*" "/tmp/**/*.*"))) - (with-open-file (out tempfile :direction :output) - (write-string "(defvar *path* #P\"XXX:XXX;FOO.LISP\")" out)) - (compile-file tempfile)) - The error message in sbcl-0.6.12.42 is - ; caught ERROR: - ; (while making load form for #) - ; A logical host can't be dumped as a constant: # - 115: reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs collection: @@ -659,19 +612,6 @@ WORKAROUND: Raymond Toy comments that this is tricky on the X86 since its FPU uses 80-bit precision internally. -120a: - The compiler incorrectly figures the return type of - (DEFUN FOO (FRAME UP-FRAME) - (IF (OR (NOT FRAME) - T) - FRAME - "BAR")) - as NIL. - - This problem exists in CMU CL 18c too. When I reported it on - cmucl-imp@cons.org, Raymond Toy replied 23 Aug 2001 with - a partial explanation, but no fix has been found yet. - 120b: Even in sbcl-0.pre7.x, which is supposed to be free of the old non-ANSI behavior of treating the function return type inferred @@ -685,7 +625,9 @@ WORKAROUND: (IF (NOT (IGNORE-ERRORS ..))). E.g. (defun foo1i () (if (not (ignore-errors - (make-pathname :host "foo" :directory "!bla" :name "bar"))) + (make-pathname :host "foo" + :directory "!bla" + :name "bar"))) (print "ok") (error "notunlessnot"))) The (NOT (IGNORE-ERRORS ..)) form evaluates to T, so this should be @@ -698,18 +640,6 @@ WORKAROUND: #+NIL) and I'd like to go back to see whether this really is a compiler bug before I delete this BUGS entry. -123: - The *USE-IMPLEMENTATION-TYPES* hack causes bugs, particularly - (IN-PACKAGE :SB-KERNEL) - (TYPE= (SPECIFIER-TYPE '(VECTOR T)) - (SPECIFIER-TYPE '(VECTOR UNDEFTYPE))) - Then because of this, the compiler bogusly optimizes - (TYPEP #(11) '(SIMPLE-ARRAY UNDEF-TYPE 1)) - to T. Unfortunately, just setting *USE-IMPLEMENTATION-TYPES* to - NIL around sbcl-0.pre7.14.flaky4.12 didn't work: the compiler complained - about type mismatches (probably harmlessly, another instance of bug 117); - and then cold init died with a segmentation fault. - 124: As of version 0.pre7.14, SBCL's implementation of MACROLET makes the entire lexical environment at the point of MACROLET available @@ -781,65 +711,6 @@ WORKAROUND: (bar x))) shouldn't compile without error (because of the extra DEFMACRO symbol). -131: - As of sbcl-0.pre7.86.flaky7.3, the cross-compiler, and probably - the CL:COMPILE function (which is based on the same %COMPILE - mechanism) get confused by -(defun sxhash (x) - (labels ((sxhash-number (x) - (etypecase x - (fixnum (sxhash x)) ; through DEFTRANSFORM - (integer (sb!bignum:sxhash-bignum x)) - (single-float (sxhash x)) ; through DEFTRANSFORM - (double-float (sxhash x)) ; through DEFTRANSFORM - #!+long-float (long-float (error "stub: no LONG-FLOAT")) - (ratio (let ((result 127810327)) - (declare (type fixnum result)) - (mixf result (sxhash-number (numerator x))) - (mixf result (sxhash-number (denominator x))) - result)) - (complex (let ((result 535698211)) - (declare (type fixnum result)) - (mixf result (sxhash-number (realpart x))) - (mixf result (sxhash-number (imagpart x))) - result)))) - (sxhash-recurse (x &optional (depthoid +max-hash-depthoid+)) - (declare (type index depthoid)) - (typecase x - (list - (if (plusp depthoid) - (mix (sxhash-recurse (car x) (1- depthoid)) - (sxhash-recurse (cdr x) (1- depthoid))) - 261835505)) - (instance - (if (typep x 'structure-object) - (logxor 422371266 - (sxhash ; through DEFTRANSFORM - (class-name (layout-class (%instance-layout x))))) - 309518995)) - (symbol (sxhash x)) ; through DEFTRANSFORM - (number (sxhash-number x)) - (array - (typecase x - (simple-string (sxhash x)) ; through DEFTRANSFORM - (string (%sxhash-substring x)) - (bit-vector (let ((result 410823708)) - (declare (type fixnum result)) - (dotimes (i (min depthoid (length x))) - (mixf result (aref x i))) - result)) - (t (logxor 191020317 (sxhash (array-rank x)))))) - (character - (logxor 72185131 - (sxhash (char-code x)))) ; through DEFTRANSFORM - (t 42)))) - (sxhash-recurse x))) - complaining "function called with two arguments, but wants exactly - one" about SXHASH-RECURSE. (This might not be strictly a new bug, - since IIRC post-fork CMU CL has also had problems with &OPTIONAL - arguments in FLET/LABELS: it might be an old Python bug which is - only exercised by the new arrangement of the SBCL compiler.) - 135: Ideally, uninterning a symbol would allow it, and its associated FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However, @@ -886,7 +757,7 @@ WORKAROUND: This bug was fixed in sbcl-0.7.4.1 by invalidating the PCL wrapper class upon redefinition. Unfortunately, doing so causes bug #176 to - appear. Pending further investication, one or other of these bugs + appear. Pending further investigation, one or other of these bugs might be present at any given time. 141: @@ -897,12 +768,6 @@ WORKAROUND: * (lisp-implementation-version) "0.pre7.129" -142: - (as reported by Lynn Quam on cmucl-imp ca. 2002-01-16) - %NATURALIZE-C-STRING conses a lot, like 16 bytes per byte - of the naturalized string. We could probably port the patches - from the cmucl-imp mailing list. - 143: (reported by Jesse Bouwman 2001-10-24 through the unfortunately prominent SourceForge web/db bug tracking system, which is @@ -987,25 +852,6 @@ WORKAROUND: 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. -153: - (essentially the same problem as a CMU CL bug reported by Martin - Cracauer on cmucl-imp 2002-02-19) - There is a hole in structure slot type checking. Compiling and LOADing - (declaim (optimize safety)) - (defstruct foo - (bla 0 :type fixnum)) - (defun f () - (let ((foo (make-foo))) - (setf (foo-bla foo) '(1 . 1)) - (format t "Is ~a of type ~a a cons? => ~a~%" - (foo-bla foo) - (type-of (foo-bla foo)) - (consp (foo-bla foo))))) - (f) - should signal an error, but in sbcl-0.7.1.21 instead gives the output - Is (1 . 1) of type CONS a cons? => NIL - without signalling an error. - 157: Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and UPGRADED-COMPLEX-PART-TYPE should have an optional environment argument. @@ -1031,27 +877,6 @@ WORKAROUND: isn't too surprising since there are many differences in stack implementation and GC conservatism between the X86 and other ports.) -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 - following code demonstrates the problem: - - (defun foo (x) - (declare (type (vector bar) x)) - (aref x 1)) - (deftype bar () 'single-float) - (foo (make-array 3 :element-type 'bar)) - -> TYPE-ERROR "The value #(0.0 0.0 0.0) is not of type (VECTOR BAR)." - (typep (make-array 3 :element-type 'bar) '(vector bar)) - -> T - - The easy solution is to make the functions which depend on knowing - the upgraded-array-element-type (in compiler/array-tran and - compiler/generic/vm-tran as of sbcl-0.7.3.x) be slightly smarter about - unknown types; an alternative is to have the - specialized-element-type slot in the ARRAY-TYPE structure be - *WILD-TYPE* for UNKNOWN-TYPE element types. - 166: Compiling (in-package :cl-user) @@ -1091,23 +916,6 @@ 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: @@ -1131,19 +939,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. -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 @@ -1188,18 +983,6 @@ WORKAROUND: (defun bug178alternative (x) (funcall (the nil x))) -181: "bad type specifier drops compiler into debugger" - Compiling - (in-package :cl-user) - (defun bar (x) - (declare (type 0 x)) - (cons x x)) - signals - bad thing to be a type specifier: 0 - which seems fine, but also enters the debugger (instead of having - the compiler handle the error, convert it into a COMPILER-ERROR, and - continue compiling) which seems wrong. - 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 @@ -1334,7 +1117,7 @@ WORKAROUND: only sporadically reproducible. 191: "Miscellaneous PCL deficiencies" - (reported by Alexey Dejenka sbcl-devel 2002-08-04) + (reported by Alexey Dejneka sbcl-devel 2002-08-04) a. DEFCLASS does not inform the compiler about generated functions. Compiling a file with (DEFCLASS A-CLASS () @@ -1345,9 +1128,140 @@ WORKAROUND: results in a STYLE-WARNING: undefined-function SB-SLOT-ACCESSOR-NAME::|COMMON-LISP-USER A-CLASS-X slot READER| + + APD's fix for this was checked in to sbcl-0.7.6.20, but Pierre + Mai points out that the declamation of functions is in fact + incorrect in some cases (most notably for structure + classes). This means that at present erroneous attempts to use + WITH-SLOTS and the like on classes with metaclass STRUCTURE-CLASS + won't get the corresponding STYLE-WARNING. c. the examples in CLHS 7.6.5.1 (regarding generic function lambda lists and &KEY arguments) do not signal errors when they should. +192: "Python treats free type declarations as promises." + b. What seemed like the same fundamental problem as bug 192a, but + was not fixed by the same (APD "more strict type checking + sbcl-devel 2002-08-97) patch: + (DOTIMES (I ...) (DOTIMES (J ...) (DECLARE ...) ...)): + (declaim (optimize (speed 1) (safety 3))) + (defun trust-assertion (i) + (dotimes (j i) + (declare (type (mod 4) i)) ; when commented out, behavior changes! + (unless (< i 5) + (print j)))) + (trust-assertion 6) ; prints nothing unless DECLARE is commented out + +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). + +194: "no error from (THE REAL '(1 2 3)) in some cases" + fixed parts: + a. In sbcl-0.7.7.9, + (multiple-value-prog1 (progn (the real '(1 2 3)))) + 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 + (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))))) + 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). + d. At the REPL, + (null (ignore-errors + (let ((arg1 1) + (arg2 (identity (the real #(1 2 3))))) + (if (< arg1 arg2) arg1 arg2)))) + => T + but putting the same expression inside (DEFUN FOO () ...), + (FOO) => NIL. + notes: + * Actually this entry is probably multiple bugs, as + Alexey Dejneka commented on sbcl-devel 2002-09-03:) + I don't think that placing these two bugs in one entry is + a good idea: they have different explanations. The second + (min 1 nil) is caused by flushing of unused code--IDENTITY + can do nothing with it. So it is really bug 122. The first + (min nil) is due to M-V-PROG1: substituting a continuation + for the result, it forgets about type assertion. The purpose + of IDENTITY is to save the restricted continuation from + inaccurate transformations. + * Alexey Dejneka pointed out that + (IGNORE-ERRORS (IDENTITY (THE REAL '(1 2 3)))) + works as it should. Also + (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. + +201: "Incautious type inference from compound CONS types" + (reported by APD sbcl-devel 2002-09-17) + (DEFUN FOO (X) + (LET ((Y (CAR (THE (CONS INTEGER *) X)))) + (SETF (CAR X) NIL) + (FORMAT NIL "~S IS ~S, Y = ~S" + (CAR X) + (TYPECASE (CAR X) + (INTEGER 'INTEGER) + (T '(NOT INTEGER))) + Y))) + + (FOO ' (1 . 2)) => "NIL IS INTEGER, Y = 1" + +202: + In 0.6.12.43 compilation of a function definition, contradicting its + FTYPE proclamation, causes an error, e.g. COMPILE-FILE on + + (declaim (ftype (function () null) foo)) + (defun foo () t) + + fails with + + debugger invoked on condition of type UNBOUND-VARIABLE: + The variable SB-C::*ERROR-FUNCTION* is unbound. + + in + + (SB-C::NOTE-LOSSAGE + "~@" + (FUNCTION NIL NULL) + (FUNCTION NIL #)) + + (In 0.7.0 the variable was renamed to SB-C::*LOSSAGE-FUN*.) + DEFUNCT CATEGORIES OF BUGS IR1-#: These labels were used for bugs related to the old IR1 interpreter.