X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=d9e91f41cdf3948e66ac046d5f2a034273400cf4;hb=e1ba5a0d68ff8d4c8e688cd6a951aea1d56b1b61;hp=58bd328a59599e721f2e2cf1fc523078f8018cbf;hpb=05f01eeac89abd78d5d16c04bf31f0b1b0076213;p=sbcl.git diff --git a/BUGS b/BUGS index 58bd328..d9e91f4 100644 --- a/BUGS +++ b/BUGS @@ -89,6 +89,9 @@ WORKAROUND: also unstable in several ways, including its inability to really grok function declarations. + As of sbcl-0.7.5, sbcl's cross-compiler does run with + *TYPE-SYSTEM-INITIALIZED*; however, this bug remains. + 7: The "compiling top-level form:" output ought to be condensed. Perhaps any number of such consecutive lines ought to turn into a @@ -180,7 +183,8 @@ 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 + (or (FOO 1000.5), "exactly 1001.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 @@ -273,22 +277,11 @@ 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. 48: SYMBOL-MACROLET bugs reported by Peter Van Eynde July 25, 2000: - a: (SYMBOL-MACROLET ((T TRUE)) ..) should probably signal - PROGRAM-ERROR, but SBCL accepts it instead. - b: SYMBOL-MACROLET should refuse to bind something which is - declared as a global variable, signalling PROGRAM-ERROR. c: SYMBOL-MACROLET should signal PROGRAM-ERROR if something it binds is declared SPECIAL inside. @@ -381,59 +374,6 @@ WORKAROUND: the new output block should start indented 2 or more characters rightward of the correct location. -65: - (probably related to bug #70; maybe related to bug #109) - As reported by Carl Witty on submit@bugs.debian.org 1999-05-08, - compiling this file -(in-package "CL-USER") -(defun equal-terms (termx termy) - (labels - ((alpha-equal-bound-term-lists (listx listy) - (or (and (null listx) (null listy)) - (and listx listy - (let ((bindings-x (bindings-of-bound-term (car listx))) - (bindings-y (bindings-of-bound-term (car listy)))) - (if (and (null bindings-x) (null bindings-y)) - (alpha-equal-terms (term-of-bound-term (car listx)) - (term-of-bound-term (car listy))) - (and (= (length bindings-x) (length bindings-y)) - (prog2 - (enter-binding-pairs (bindings-of-bound-term (car listx)) - (bindings-of-bound-term (car listy))) - (alpha-equal-terms (term-of-bound-term (car listx)) - (term-of-bound-term (car listy))) - (exit-binding-pairs (bindings-of-bound-term (car listx)) - (bindings-of-bound-term (car listy))))))) - (alpha-equal-bound-term-lists (cdr listx) (cdr listy))))) - - (alpha-equal-terms (termx termy) - (if (and (variable-p termx) - (variable-p termy)) - (equal-bindings (id-of-variable-term termx) - (id-of-variable-term termy)) - (and (equal-operators-p (operator-of-term termx) (operator-of-term termy)) - (alpha-equal-bound-term-lists (bound-terms-of-term termx) - (bound-terms-of-term termy)))))) - - (or (eq termx termy) - (and termx termy - (with-variable-invocation (alpha-equal-terms termx termy)))))) - causes an assertion failure - The assertion (EQ (C::LAMBDA-TAIL-SET C::CALLER) - (C::LAMBDA-TAIL-SET (C::LAMBDA-HOME C::CALLEE))) failed. - - Bob Rogers reports (1999-07-28 on cmucl-imp@cons.org) a smaller test - case with the same problem: -(defun parse-fssp-alignment () - ;; Given an FSSP alignment file named by the argument . . . - (labels ((get-fssp-char () - (get-fssp-char)) - (read-fssp-char () - (get-fssp-char))) - ;; Stub body, enough to tickle the bug. - (list (read-fssp-char) - (read-fssp-char)))) - 66: ANSI specifies that the RESULT-TYPE argument of CONCATENATE must be a subtype of SEQUENCE, but CONCATENATE doesn't check this properly: @@ -451,6 +391,8 @@ WORKAROUND: doesn't seem to exist for sequence types: (DEFTYPE BAR () 'SIMPLE-VECTOR) (CONCATENATE 'BAR #(1 2) '(3)) => #(1 2 3) + See also bug #46a./b., and discussion and patch sbcl-devel and + cmucl-imp 2002-07 67: As reported by Winton Davies on a CMU CL mailing list 2000-01-10, @@ -458,27 +400,6 @@ WORKAROUND: crashes SBCL. In general tracing anything which is used in the implementation of TRACE is likely to have the same problem. -70: - (probably related to bug #65; maybe related to bug #109) - The compiler doesn't like &OPTIONAL arguments in LABELS and FLET - forms. E.g. - (DEFUN FIND-BEFORE (ITEM SEQUENCE &KEY (TEST #'EQL)) - (LABELS ((FIND-ITEM (OBJ SEQ TEST &OPTIONAL (VAL NIL)) - (LET ((ITEM (FIRST SEQ))) - (COND ((NULL SEQ) - (VALUES NIL NIL)) - ((FUNCALL TEST OBJ ITEM) - (VALUES VAL SEQ)) - (T - (FIND-ITEM OBJ (REST SEQ) TEST (NCONC VAL `(,ITEM)))))))) - (FIND-ITEM ITEM SEQUENCE TEST))) - from David Young's bug report on cmucl-help@cons.org 30 Nov 2000 - causes sbcl-0.6.9 to fail with - error in function SB-KERNEL:ASSERT-ERROR: - The assertion (EQ (SB-C::LAMBDA-TAIL-SET SB-C::CALLER) - (SB-C::LAMBDA-TAIL-SET - (SB-C::LAMBDA-HOME SB-C::CALLEE))) failed. - 72: (DECLAIM (OPTIMIZE ..)) doesn't work properly inside LOCALLY forms. @@ -540,14 +461,6 @@ WORKAROUND: (I haven't tried to investigate this bug enough to guess whether there might be any user-level symptoms.) -90: - a latent cross-compilation/bootstrapping bug: The cross-compilation - host's CL:CHAR-CODE-LIMIT is used in target code in readtable.lisp - and possibly elsewhere. Instead, we should use the target system's - CHAR-CODE-LIMIT. This will probably cause problems if we try to - bootstrap on a system which uses a different value of CHAR-CODE-LIMIT - than SBCL does. - 94a: Inconsistencies between derived and declared VALUES return types for DEFUN aren't checked very well. E.g. the logic which successfully @@ -626,15 +539,6 @@ WORKAROUND: the first time around, until regression tests are written I'm not comfortable merging the patches in the CVS version of SBCL. -102: - As reported by Arthur Lemmens sbcl-devel 2001-05-05, ANSI - requires that SYMBOL-MACROLET refuse to rebind special variables, - 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.7.3.x, this dependence on the nonconforming behavior - has been fixed, but the nonconforming behavior remains.) - 104: (DESCRIBE 'SB-ALIEN:DEF-ALIEN-TYPE) reports the macro argument list incorrectly: @@ -654,25 +558,6 @@ WORKAROUND: time trying to GC afterwards. Surely there's some more economical way to implement (ROOM T). -109: - reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs - collection: - ;;; This file fails to compile. - ;;; Maybe this bug is related to bugs #65, #70 in the BUGS file. - (in-package :cl-user) - (defun tst2 () - (labels - ((eff (&key trouble) - (eff) - ;; nil - ;; Uncomment and it works - )) - (eff))) - In SBCL 0.6.12.42, the problem is - internal error, failed AVER: - "(COMMON-LISP:EQ (SB!C::LAMBDA-TAIL-SET SB!C::CALLER) - (SB!C::LAMBDA-TAIL-SET (SB!C::LAMBDA-HOME SB!C::CALLEE)))" - 110: reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs collection: @@ -691,25 +576,6 @@ WORKAROUND: 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: @@ -768,19 +634,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 @@ -794,7 +647,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 @@ -807,18 +662,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 @@ -1068,6 +911,8 @@ WORKAROUND: It should be possible to be much more specific (overflow, division by zero, etc.) and of course the "How can this be?" should be fixable. + 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) @@ -1113,18 +958,6 @@ WORKAROUND: Is (1 . 1) of type CONS a cons? => NIL without signalling an error. -154: - There's some sort of problem with aborting back out of the debugger - after a %DETECT-STACK-EXHAUSTION error in sbcl-0.7.1.38. In some cases - telling the debugger to ABORT doesn't get you back to the main REPL, - but instead just gives you another stack exhaustion error. The problem - doesn't occur in the trivial case - * (defun frob () (frob) (frob)) - FROB - * (frob) - but it has happened in more complicated cases (which I haven't - figured out how to reproduce). - 157: Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and UPGRADED-COMPLEX-PART-TYPE should have an optional environment argument. @@ -1150,27 +983,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) @@ -1222,11 +1034,6 @@ WORKAROUND: 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: @@ -1250,19 +1057,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 @@ -1344,12 +1138,6 @@ WORKAROUND: :ACCRUED-EXCEPTIONS (:INEXACT) :FAST-MODE NIL) -184: "division by zero becomes frozen into RATIO" - (reported by Wolfhard Buss on cmucl-imp 18 Jun 2002, fails on - sbcl-0.7.4.39 too) - * (/ 1 (/ 3 2) 0) - 1/0 - 185: "top-level forms at the REPL" * (locally (defstruct foo (a 0 :type fixnum))) gives an error: @@ -1416,7 +1204,9 @@ WORKAROUND: (sb-c::%dvai v i)) 188: "compiler performance fiasco involving type inference and UNION-TYPE" - In sbcl-0.7.5.11 on a 700 MHz Pentium III, + (In sbcl-0.7.6.10, DEFTRANSFORM CONCATENATE was commented out until this + bug could be fixed properly, so you won't see the bug unless you restore + the DEFTRANSFORM by hand.) In sbcl-0.7.5.11 on a 700 MHz Pentium III, (time (compile nil '(lambda () @@ -1450,8 +1240,158 @@ WORKAROUND: (INTEGER 1296 1296) ...)>)[:EXTERNAL] -(189: "ignored NOTINLINE for functions defined by FLET or LABELS") - (fixed in sbcl-0.7.6.3) +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 + is a classic symptom of buffer filling and deadlock, but it seems + only sporadically reproducible. + +191: "Miscellaneous PCL deficiencies" + (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 () + ((A-CLASS-X))) + (DEFUN A-CLASS-X (A) + (WITH-SLOTS (A-CLASS-X) A + A-CLASS-X)) + 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? + +195: "confusing reporting of not-a-REAL TYPE-ERRORs from THE REAL" + In sbcl-0.7.7.10, (THE REAL #(1 2 3)) signals a type error which + prints as "This is not a (OR SINGLE-FLOAT DOUBLE-FLOAT RATIONAL)". + The (OR SINGLE-FLOAT DOUBLE-FLOAT RATIONAL) representation of + REAL is unnecessarily confusing, especially since it relies on + internal implementation knowledge that even with SHORT-FLOAT + and LONG-FLOAT left out of the union, this type is equal to REAL. + So it'd be better just to say "This is not a REAL". + +196: "confusing error message for unREAL second arg to ATAN" + (fixed in sbcl-0.7.7.18) + +197: "failed AVER on compiling or evaluating function constants" + (reported by Antonio Martinez sbcl-devel 2002-09-12) + When compiling or evaluating function constants, such as in + (EVAL `(LAMBDA () (FUNCALL ,(LAMBDA () NIL)))) + I get the following error message: + debugger invoked on condition of type SB-INT:BUG: + failed AVER: "(LEAF-HAS-SOURCE-NAME-P LEAF)" + + Although this seems a dubious use of function constants, it would be + good either to make it work or to produce a useful error message. + +198: "conflicting THEs are not necessarily all checked" + (reported by APD sbcl-devel 2002-09-14) + (DEFUN FOO (X) + (LET (Y) + (SETF Y (THE SINGLE-FLOAT (THE INTEGER X))) + (LIST Y Y))) + + (FOO 3) => error "3 is not of type SINGLE-FLOAT" + (FOO 3F0) => (3F0 3F0) + + APD also reports that this code has not worked as intended in SBCL + since the days of sbcl-0.7.0, while CMUCL correctly detects the type + error ("is not of type NIL") for all inputs. + +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. DEFUNCT CATEGORIES OF BUGS IR1-#: