X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=729c8d2e7a2c52892239aef52d19dab2ae3e166c;hb=9a2e730f74641e7de6ad4099111db92c5ad863bf;hp=6fd716f2b62cf82f60f7defccab8c493f6867edd;hpb=9347abeb5f42dc83d372c19b14e86204a6a588dd;p=sbcl.git diff --git a/BUGS b/BUGS index 6fd716f..729c8d2 100644 --- a/BUGS +++ b/BUGS @@ -1,4 +1,4 @@ -REPORTING BUGS +tREPORTING BUGS Bugs can be reported on the help mailing list sbcl-help@lists.sourceforge.net @@ -659,19 +659,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 @@ -698,18 +685,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 @@ -1031,27 +1006,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) @@ -1334,7 +1288,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 +1299,96 @@ 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." + a. original report by Alexey Dejneka (on sbcl-devel 2002-08-26): + (declaim (optimize (speed 0) (safety 3))) + (defun f (x) + (declare (real x)) + (+ x + (locally (declare (single-float x)) + (sin x)))) + Now (F NIL) correctly gives a type error, but (F 100) gives + a segmentation violation. + b. same fundamental problem in a different way, easy to stumble + across if you mistype and declare the wrong index in + (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" + In sbcl-0.7.7.9, + (multiple-value-prog1 (progn (the real '(1 2 3)))) + returns (1 2 3) instead of signalling an error. Also in sbcl-0.7.7.9, + a more complicated instance of this bug kept + (IGNORE-ERRORS (MIN '(1 2 3))) from returning NIL as it should when + the MIN source transform expanded to (THE REAL '(1 2 3)), because + (IGNORE-ERRORS (THE REAL '(1 2 3))) returns (1 2 3). + Alexey Dejneka pointed out that + (IGNORE-ERRORS (IDENTITY (THE REAL '(1 2 3)))) works as it should. + (IGNORE-ERRORS (VALUES (THE REAL '(1 2 3)))) also works as it should. + Perhaps this is another case of VALUES type intersections behaving + in non-useful ways? + When I (WHN) tried to use the VALUES trick to work around this bug + in the MIN source transform, it didn't work for + (assert (null (ignore-errors (min 1 #(1 2 3))))) + Hand-expanding the source transform, I get + (assert (null (ignore-errors + (let ((arg1 1) + (arg2 (identity (the real #(1 2 3))))) + (if (< arg1 arg2) arg1 arg2))))) + which fails (i.e. the assertion fails, because the IGNORE-ERRORS + doesn't report MIN signalling a type error). At the REPL + (null (ignore-errors + (let ((arg1 1) + (arg2 (identity (the real #(1 2 3))))) + (if (< arg1 arg2) arg1 arg2)))) + => T + but when this expression is used as the body of (DEFUN FOO () ...) + then (FOO)=>NIL. + +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". + DEFUNCT CATEGORIES OF BUGS IR1-#: These labels were used for bugs related to the old IR1 interpreter.