X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;ds=sidebyside;f=BUGS;h=60c65055bff40ec595fdb1405fe98b7b98445df9;hb=369029d73f198b59135c6c005b7a70ae5a753650;hp=f4a9efc80c7a2f5dc548a64b2cbaa12dc151c85b;hpb=48b4e7d2121bc92ed4b4ed0951b85e764f864f05;p=sbcl.git diff --git a/BUGS b/BUGS index f4a9efc..60c6505 100644 --- a/BUGS +++ b/BUGS @@ -1,4 +1,4 @@ -tREPORTING BUGS +REPORTING BUGS Bugs can be reported on the help mailing list sbcl-help@lists.sourceforge.net @@ -183,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 @@ -276,13 +277,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. @@ -582,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: @@ -659,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 @@ -685,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 @@ -1070,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: @@ -1098,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 @@ -1312,9 +1258,101 @@ 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? + +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) + DEFUNCT CATEGORIES OF BUGS IR1-#: These labels were used for bugs related to the old IR1 interpreter.