-REPORTING BUGS
+tREPORTING BUGS
Bugs can be reported on the help mailing list
sbcl-help@lists.sourceforge.net
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
#+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
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)
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 ()
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
+ #<STANDARD-GENERIC-FUNCTION FOO (1)>.
+ 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.
projects / sbcl.git / blobdiff