X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=5d4a77904f3e832025da590dd767aff10beeec7b;hb=d323b0249b9b1e4a91ddf8716ac9185cd268d973;hp=8ee489161546ea3434da88812abd4a9a1f974903;hpb=34dd23563d2f5cf05c72b971da0d0b065a09bf2a;p=sbcl.git diff --git a/BUGS b/BUGS index 8ee4891..5d4a779 100644 --- a/BUGS +++ b/BUGS @@ -248,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: @@ -330,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 @@ -367,20 +350,6 @@ WORKAROUND: The implementation of #'+ returns its single argument without type checking, e.g. (+ "illegal") => "illegal". -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. @@ -529,18 +498,6 @@ WORKAROUND: 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 @@ -617,9 +574,6 @@ WORKAROUND: 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)) @@ -1061,20 +1015,6 @@ WORKAROUND: 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, @@ -1131,6 +1071,11 @@ WORKAROUND: 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: @@ -1275,19 +1220,98 @@ WORKAROUND: 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. -149: - (reported by Stig E Sandoe sbcl-devel 2002-02-02) - In sbcl-0.7.1.13, compiling a DEFCLASS FOO form isn't enough to make - the class known to the compiler for other forms compiled in the same - file, so bogus warnings "undefined type: FOO" are generated, e.g. - when compiling - (in-package :cl-user) - (defclass foo () ()) - (defun bar (x) - (typep x 'foo)) +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.