X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=5d4a77904f3e832025da590dd767aff10beeec7b;hb=d323b0249b9b1e4a91ddf8716ac9185cd268d973;hp=14bfd66f743b64add181e252b889c85494102c55;hpb=a8f0175b16a00f5fc83eb8d8a718ae7fc5497514;p=sbcl.git diff --git a/BUGS b/BUGS index 14bfd66..5d4a779 100644 --- a/BUGS +++ b/BUGS @@ -137,6 +137,8 @@ WORKAROUND: (defclass ccc () ()) (setf (find-class 'ccc1) (find-class 'ccc)) (defmethod zut ((c ccc1)) 123) + In sbcl-0.7.1.13, this gives an error, + There is no class named CCC1. DTC's recommended workaround from the mailing list 3 Mar 2000: (setf (pcl::find-class 'ccc1) (pcl::find-class 'ccc)) @@ -246,12 +248,6 @@ WORKAROUND: ANSI spec, bare 'MEMBER, 'AND, and 'OR are not legal types, CMUCL (and now SBCL) interpret them as legal types. -44: - ANSI specifies DEFINE-SYMBOL-MACRO, but it's not defined in SBCL. - CMU CL added it ca. Aug 13, 2000, after some discussion on the mailing - list, and it is probably possible to use substantially the same - patches to add it to SBCL. - 45: a slew of floating-point-related errors reported by Peter Van Eynde on July 25, 2000: @@ -328,17 +324,6 @@ WORKAROUND: c: SYMBOL-MACROLET should signal PROGRAM-ERROR if something it binds is declared SPECIAL inside. -50: - type system errors reported by Peter Van Eynde July 25, 2000: - c: (SUBTYPEP '(INTEGER (0) (0)) 'NIL) dies with nested errors. - d: In general, the system doesn't like '(INTEGER (0) (0)) -- it - blows up at the level of SPECIFIER-TYPE with - "Lower bound (0) is greater than upper bound (0)." Probably - SPECIFIER-TYPE should return the NIL type instead. - g: The type system isn't all that smart about relationships - between hairy types, as shown in the type.erg test results, - e.g. (SUBTYPEP 'CONS '(NOT ATOM)) => NIL, NIL. - 51: miscellaneous errors reported by Peter Van Eynde July 25, 2000: a: (PROGN @@ -365,27 +350,6 @@ WORKAROUND: The implementation of #'+ returns its single argument without type checking, e.g. (+ "illegal") => "illegal". -56: - Attempting to use COMPILE on something defined by DEFMACRO fails: - (DEFMACRO FOO (X) (CONS X X)) - (COMPILE 'FOO) -Error in function C::GET-LAMBDA-TO-COMPILE: - # was defined in a non-null environment. - -58: - (SUBTYPEP '(AND ZILCH INTEGER) 'ZILCH) => NIL, NIL - Note: I looked into fixing this in 0.6.11.15, but gave up. The - problem seems to be that there are two relevant type methods for - the subtypep operation, HAIRY :COMPLEX-SUBTYPEP-ARG2 and - INTERSECTION :COMPLEX-SUBTYPEP-ARG1, and only the first is - called. This could be fixed, but type dispatch is messy and - confusing enough already, I don't want to complicate it further. - Perhaps someday we can make CLOS cross-compiled (instead of compiled - after bootstrapping) so that we don't need to have the type system - available before CLOS, and then we can rewrite the type methods to - CLOS methods, and then expressing the solutions to stuff like this - should become much more straightforward. -- WHN 2001-03-14 - 60: The debugger LIST-LOCATIONS command doesn't work properly. @@ -534,18 +498,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: it should probably look at the class name, the way that it does for STRUCTURE-OBJECTs. -69: - As reported by Martin Atzmueller on the sbcl-devel list 2000-11-22, - > There remains one issue, that is a bug in SBCL: - > According to my interpretation of the spec, the ":" and "@" modifiers - > should appear _after_ the comma-seperated arguments. - > Well, SBCL (and CMUCL for that matter) accept - > (ASSERT (STRING= (FORMAT NIL "~:8D" 1) " 1")) - > where the correct way (IMHO) should be - > (ASSERT (STRING= (FORMAT NIL "~8:D" 1) " 1")) - Probably SBCL should stop accepting the "~:8D"-style format arguments, - or at least issue a warning. - 70: (probably related to bug #65; maybe related to bug #109) The compiler doesn't like &OPTIONAL arguments in LABELS and FLET @@ -622,9 +574,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: it would decrease efficiency more than is probably necessary. Perhaps using some sort of accept/reject method would be better. -84: - (SUBTYPEP '(SATISFIES SOME-UNDEFINED-FUN) NIL)=>NIL,T (should be NIL,NIL) - 85: Internally the compiler sometimes evaluates (sb-kernel:type/= (specifier-type '*) (specifier-type t)) @@ -805,30 +754,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: type declarations are supposed to be treated as assertions unless SAFETY 0, so we should be getting a TYPE-ERROR. -112: - reported by Martin Atzmueller 2001-06-25; taken from CMU CL bugs - collection; apparently originally reported by Bruno Haible - (in-package :cl-user) - ;;; From: Bruno Haible - ;;; Subject: scope of SPECIAL declarations - ;;; It seems CMUCL has a bug relating to the scope of SPECIAL - ;;; declarations. I observe this with "CMU Common Lisp 18a x86-linux - ;;; 1.4.0 cvs". - (let ((x 0)) - (declare (special x)) - (let ((x 1)) - (let ((y x)) - (declare (special x)) y))) - ;;; Gives: 0 (this should return 1 according to CLHS) - (let ((x 0)) - (declare (special x)) - (let ((x 1)) - (let ((y x) (x 5)) - (declare (special x)) y))) - ;;; Gives: 1 (correct). - The reported results match what we get from the interpreter - in sbcl-0.6.12.42. - 113: reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs collection: @@ -1090,20 +1015,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: arguments in FLET/LABELS: it might be an old Python bug which is only exercised by the new arrangement of the SBCL compiler.) -132: - Trying to compile - (DEFUN FOO () (CATCH 0 (PRINT 1331))) - gives an error - # is not valid as the second argument to VOP: - SB-C:MAKE-CATCH-BLOCK, - since the TN's primitive type SB-VM::POSITIVE-FIXNUM doesn't allow - any of the SCs allowed by the operand restriction: - (SB-VM::DESCRIPTOR-REG) - The (CATCH 0 ...) construct is bad style (because of unportability - of EQ testing of numbers) but it is legal, and shouldn't cause an - internal compiler error. (This error occurs in sbcl-0.6.13 and in - 0.pre7.86.flaky7.14.) - 135: Ideally, uninterning a symbol would allow it, and its associated FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However, @@ -1160,6 +1071,11 @@ Error in function C::GET-LAMBDA-TO-COMPILE: T T + This is probably due to underzealous clearing of the type caches; a + brute-force solution in that case would be to make a defclass expand + into something that included a call to SB-KERNEL::CLEAR-TYPE-CACHES, + but there may be a better solution. + 141: Pretty-printing nested backquotes doesn't work right, as reported by Alexey Dejneka sbcl-devel 2002-01-13: @@ -1219,9 +1135,183 @@ Error in function C::GET-LAMBDA-TO-COMPILE: upgraded to do so. (This doesn't seem to be a high priority conformance problem, since seems hard to construct useful code where it matters.) - + +146: + Floating point errors are reported poorly. E.g. on x86 OpenBSD + with sbcl-0.7.1, + * (expt 2.0 12777) + debugger invoked on condition of type SB-KERNEL:FLOATING-POINT-EXCEPTION: + An arithmetic error SB-KERNEL:FLOATING-POINT-EXCEPTION was signalled. + No traps are enabled? How can this be? + It should be possible to be much more specific (overflow, division + by zero, etc.) and of course the "How can this be?" should be fixable. + +147: + (reported by Alexey Dejneka sbcl-devel 2002-01-28) + Compiling a file containing + (deftype digit () '(member #\1)) + (defun parse-num (string ind) + (flet ((digs () + (let (old-index) + (if (and (< ind ind) + (typep (char string ind) 'digit)) + nil)))))) + in sbcl-0.7.1 causes the compiler to fail with + internal error, failed AVER: "(= (LENGTH (BLOCK-SUCC CALL-BLOCK)) 1)" + This problem seems to have been introduced by the sbcl-0.pre7.* compiler + changes, since 0.pre7.73 and 0.6.13 don't suffer from it. A related + test case is + (defun parse-num (index) + (let (num x) + (flet ((digs () + (setq num index)) + (z () + (let () + (setq x nil)))) + (when (and (digs) (digs)) x)))) + In sbcl-0.7.1, this second test case failed with the same + internal error, failed AVER: "(= (LENGTH (BLOCK-SUCC CALL-BLOCK)) 1)" + After the APD patches in sbcl-0.7.1.2 (new consistency check in + TARGET-IF-DESIRABLE, plus a fix in meta-vmdef.lisp to keep the + new consistency check from failing routinely) this second test case + failed in FIND-IN-PHYSENV instead. Fixes in sbcl-0.7.1.3 (not + closing over unreferenced variables) made this second test case + compile without error, but the original test case still fails. + + Another way to get rid of the DEFTYPE without changing the symptom + of the bug is + (defvar *ch*) + (defun parse-num (string ind) + (flet ((digs () + (let () + (if (and (< ind ind) + (sb-int:memq *ch* '(#\1))) + nil)))))) + In sbcl-0.7.1.3, this fails with + internal error, failed AVER: "(= (LENGTH (BLOCK-SUCC CALL-BLOCK)) 1)" + The problem occurs while the inline expansion of MEMQ, + # + is being LET-converted after having its second REF deleted, leaving + it with only one entry in LEAF-REFS. + +148: + In sbcl-0.7.1.3 on x86, COMPILE-FILE on the file + (in-package :cl-user) + (defvar *thing*) + (defvar *zoom*) + (defstruct foo bar bletch) + (defun %zeep () + (labels ((kidify1 (kid) + ) + (kid-frob (kid) + (if *thing* + (setf sweptm + (m+ (frobnicate kid) + sweptm)) + (kidify1 kid)))) + (declare (inline kid-frob)) + (map nil + #'kid-frob + (the simple-vector (foo-bar perd))))) + fails with + debugger invoked on condition of type TYPE-ERROR: + The value NIL is not of type SB-C::NODE. + The location of this failure has moved around as various related + issues were cleaned up. As of sbcl-0.7.1.9, it occurs in + NODE-BLOCK called by LAMBDA-COMPONENT called by IR2-CONVERT-CLOSURE. + +153: + (essentially the same problem as a CMU CL bug reported by Martin + Cracauer on cmucl-imp 2002-02-19) + There is a hole in structure slot type checking. Compiling and LOADing + (declaim (optimize safety)) + (defstruct foo + (bla 0 :type fixnum)) + (defun f () + (let ((foo (make-foo))) + (setf (foo-bla foo) '(1 . 1)) + (format t "Is ~a of type ~a a cons? => ~a~%" + (foo-bla foo) + (type-of (foo-bla foo)) + (consp (foo-bla foo))))) + (f) + should signal an error, but in sbcl-0.7.1.21 instead gives the output + Is (1 . 1) of type CONS a cons? => NIL + without signalling an error. + +154: + There's some sort of problem with aborting back out of the debugger + after a %DETECT-STACK-EXHAUSTION error in sbcl-0.7.1.38. In some cases + telling the debugger to ABORT doesn't get you back to the main REPL, + but instead just gives you another stack exhaustion error. The problem + doesn't occur in the trivial case + * (defun frob () (frob) (frob)) + FROB + * (frob) + but it has happened in more complicated cases (which I haven't + figured out how to reproduce). + +155: + Executing + (defclass standard-gadget (basic-gadget) ()) + (defclass basic-gadget () ()) + gives an error: + The slot SB-PCL::DIRECT-SUPERCLASSES is unbound in the + object #. + (reported by Brian Spilsbury sbcl-devel 2002-04-09) + +156: + FUNCTION-LAMBDA-EXPRESSION doesn't work right in 0.7.0 or 0.7.2.9: + * (function-lambda-expression #'(lambda (x) x)) + debugger invoked on condition of type TYPE-ERROR: + The value NIL is not of type SB-C::DEBUG-SOURCE + (reported by Alexey Dejneka sbcl-devel 2002-04-12) + +157: + Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and + UPGRADED-COMPLEX-PART-TYPE should have an optional environment argument. + (reported by Alexey Dejneka sbcl-devel 2002-04-12) + +158: + Compiling the following code causes SBCL 0.7.2 to bug. This only + happens with optimization enabled, and only when the loop variable is + being incremented by more than 1. + (defun foo (array) + (declare (optimize (safety 0) (space 0) (debug 0) (speed 3))) + (loop for i from 0 to 10 by 2 + do (foo (svref array i))) (svref array (1+ i))) + (reported by Eric Marsden sbcl-devel 2002-04-15) + +159: + * (lisp-implementation-version) + "0.7.2.6" + * (defstruct (foo + (:constructor make-foo (&key (bar nil bar-p) + &aux (baz (if bar-p bar 2))))) + + bar + baz) + debugger invoked on condition of type SB-KERNEL::ARG-COUNT-ERROR: + error while parsing arguments to DESTRUCTURING-BIND: + invalid number of elements in + (BAR NIL BAR-P) + to satisfy lambda list + (SB-KERNEL::WOT &OPTIONAL (SB-KERNEL::DEF NIL SB-KERNEL::DEF-P)): + between 1 and 2 expected, but 3 found + (reported by Christophe Rhodes and Martin Atzmueller sbcl-devel + 2002-05-15) + +160: + USER-HOMEDIR-PATHNAME returns a pathname that SBCL can't do anything + with. Probably we should return an absolute physical pathname + instead. (Reported by Peter van Eynde sbcl-devel 2002-03-29) + +161: + Typep on certain SATISFIES types doesn't take account of the fact + that the function could cause an error; e.g. (TYPEP #\! '(SATISFIES + FBOUNDP)) raises an error when it should return NIL. + DEFUNCT CATEGORIES OF BUGS IR1-#: - These numbers were used for bugs related to the old IR1 - interpreter. The # values reached 6 before the category - was closed down. \ No newline at end of file + These labels were used for bugs related to the old IR1 interpreter. + The # values reached 6 before the category was closed down.