-tREPORTING BUGS
+REPORTING BUGS
Bugs can be reported on the help mailing list
sbcl-help@lists.sourceforge.net
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
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.
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 <gadbois@cyc.com>
- ;;;
- ;;; 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 #<SB-IMPL::LOGICAL-HOST "XXX">)
- ; A logical host can't be dumped as a constant: #<SB-IMPL::LOGICAL-HOST "XXX">
-
115:
reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
collection:
(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
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:
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
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
+ #<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"
+ 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.
projects / sbcl.git / blobdiff