X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=b7c3b53bec3b73577bb584a3db48039aa8138d8d;hb=df81175171338132825adfd1e522f350878986da;hp=d9e91f41cdf3948e66ac046d5f2a034273400cf4;hpb=e1ba5a0d68ff8d4c8e688cd6a951aea1d56b1b61;p=sbcl.git diff --git a/BUGS b/BUGS index d9e91f4..b7c3b53 100644 --- a/BUGS +++ b/BUGS @@ -297,9 +297,6 @@ WORKAROUND: (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 @@ -733,65 +730,6 @@ WORKAROUND: (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, @@ -1022,18 +960,6 @@ WORKAROUND: 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: @@ -1101,18 +1027,6 @@ WORKAROUND: (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 @@ -1341,43 +1255,6 @@ WORKAROUND: 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) @@ -1393,6 +1270,42 @@ WORKAROUND: 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 + "~@" + (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.