(DEFGENERIC FOO03 (X))
(ADD-METHOD (FUNCTION FOO03) M)))
should give an error, but SBCL allows it.
- b: READ should probably return READER-ERROR, not the bare
- arithmetic error, when input a la "1/0" or "1e1000" causes
- an arithmetic error.
52:
It has been reported (e.g. by Peter Van Eynde) that there are
(bar x)))
shouldn't compile without error (because of the extra DEFMACRO symbol).
-131:
- As of sbcl-0.pre7.86.flaky7.3, the cross-compiler, and probably
- the CL:COMPILE function (which is based on the same %COMPILE
- mechanism) get confused by
-(defun sxhash (x)
- (labels ((sxhash-number (x)
- (etypecase x
- (fixnum (sxhash x)) ; through DEFTRANSFORM
- (integer (sb!bignum:sxhash-bignum x))
- (single-float (sxhash x)) ; through DEFTRANSFORM
- (double-float (sxhash x)) ; through DEFTRANSFORM
- #!+long-float (long-float (error "stub: no LONG-FLOAT"))
- (ratio (let ((result 127810327))
- (declare (type fixnum result))
- (mixf result (sxhash-number (numerator x)))
- (mixf result (sxhash-number (denominator x)))
- result))
- (complex (let ((result 535698211))
- (declare (type fixnum result))
- (mixf result (sxhash-number (realpart x)))
- (mixf result (sxhash-number (imagpart x)))
- result))))
- (sxhash-recurse (x &optional (depthoid +max-hash-depthoid+))
- (declare (type index depthoid))
- (typecase x
- (list
- (if (plusp depthoid)
- (mix (sxhash-recurse (car x) (1- depthoid))
- (sxhash-recurse (cdr x) (1- depthoid)))
- 261835505))
- (instance
- (if (typep x 'structure-object)
- (logxor 422371266
- (sxhash ; through DEFTRANSFORM
- (class-name (layout-class (%instance-layout x)))))
- 309518995))
- (symbol (sxhash x)) ; through DEFTRANSFORM
- (number (sxhash-number x))
- (array
- (typecase x
- (simple-string (sxhash x)) ; through DEFTRANSFORM
- (string (%sxhash-substring x))
- (bit-vector (let ((result 410823708))
- (declare (type fixnum result))
- (dotimes (i (min depthoid (length x)))
- (mixf result (aref x i)))
- result))
- (t (logxor 191020317 (sxhash (array-rank x))))))
- (character
- (logxor 72185131
- (sxhash (char-code x)))) ; through DEFTRANSFORM
- (t 42))))
- (sxhash-recurse x)))
- complaining "function called with two arguments, but wants exactly
- one" about SXHASH-RECURSE. (This might not be strictly a new bug,
- since IIRC post-fork CMU CL has also had problems with &OPTIONAL
- arguments in FLET/LABELS: it might be an old Python bug which is
- only exercised by the new arrangement of the SBCL compiler.)
-
135:
Ideally, uninterning a symbol would allow it, and its associated
FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However,
macro is unhappy with the illegal syntax in the method body, and
is giving an unclear error message.
-168:
- (reported by Dan Barlow on sbcl-devel 2002-05-10)
- In sbcl-0.7.3.12, doing
- (defstruct foo bar baz)
- (compile nil (lambda (x) (or x (foo-baz x))))
- gives an error
- debugger invoked on condition of type SB-INT:BUG:
- full call to SB-KERNEL:%INSTANCE-REF
- This is probably a bug in SBCL itself. [...]
- Since this is a reasonable user error, it shouldn't be reported as
- an SBCL bug.
-
172:
sbcl's treatment of at least macro lambda lists is too permissive;
e.g., in sbcl-0.7.3.7:
(defun bug178alternative (x)
(funcall (the nil x)))
-181: "bad type specifier drops compiler into debugger"
- Compiling
- (in-package :cl-user)
- (defun bar (x)
- (declare (type 0 x))
- (cons x x))
- signals
- bad thing to be a type specifier: 0
- which seems fine, but also enters the debugger (instead of having
- the compiler handle the error, convert it into a COMPILER-ERROR, and
- continue compiling) which seems wrong.
-
183: "IEEE floating point issues"
Even where floating point handling is being dealt with relatively
well (as of sbcl-0.7.5, on sparc/sunos and alpha; see bug #146), the
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)
APD further reports that this bug is not present in CMUCL.
+201: "Incautious type inference from compound CONS types"
+ (reported by APD sbcl-devel 2002-09-17)
+ (DEFUN FOO (X)
+ (LET ((Y (CAR (THE (CONS INTEGER *) X))))
+ (SETF (CAR X) NIL)
+ (FORMAT NIL "~S IS ~S, Y = ~S"
+ (CAR X)
+ (TYPECASE (CAR X)
+ (INTEGER 'INTEGER)
+ (T '(NOT INTEGER)))
+ Y)))
+
+ (FOO ' (1 . 2)) => "NIL IS INTEGER, Y = 1"
+
+202:
+ In 0.6.12.43 compilation of a function definition, contradicting its
+ FTYPE proclamation, causes an error, e.g. COMPILE-FILE on
+
+ (declaim (ftype (function () null) foo))
+ (defun foo () t)
+
+ fails with
+
+ debugger invoked on condition of type UNBOUND-VARIABLE:
+ The variable SB-C::*ERROR-FUNCTION* is unbound.
+
+ in
+
+ (SB-C::NOTE-LOSSAGE
+ "~@<The previously declared FTYPE~2I ~_~S~I ~_~
+ conflicts with the definition type ~2I~_~S~:>"
+ (FUNCTION NIL NULL)
+ (FUNCTION NIL #))
+
+ (In 0.7.0 the variable was renamed to SB-C::*LOSSAGE-FUN*.)
+
DEFUNCT CATEGORIES OF BUGS
IR1-#:
These labels were used for bugs related to the old IR1 interpreter.
projects / sbcl.git / blobdiff