X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=fc576e00d4898b7e9e6dc60e811fd2c741e1550f;hb=ba38798a5ca26b90647a1993f348806cb32f2d1b;hp=115b769381e6b93c9c16cb46d75ab0652cab9501;hpb=78a057624fecd10d0fb2ead4ef02ffc361b1ee22;p=sbcl.git diff --git a/BUGS b/BUGS index 115b769..fc576e0 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)) @@ -640,18 +594,6 @@ WORKAROUND: bootstrap on a system which uses a different value of CHAR-CODE-LIMIT than SBCL does. -91: - (subtypep '(or (integer -1 1) - unsigned-byte) - '(or (rational -1 7) - unsigned-byte - (integer -1 1))) => NIL,T - An analogous problem with SINGLE-FLOAT and REAL types was fixed in - sbcl-0.6.11.22, but some peculiarites of the RATIO type make it - awkward to generalize the fix to INTEGER and RATIONAL. It's not - clear what's the best fix. (See the "bug in type handling" discussion - on cmucl-imp ca. 2001-03-22 and ca. 2001-02-12.) - 94a: Inconsistencies between derived and declared VALUES return types for DEFUN aren't checked very well. E.g. the logic which successfully @@ -1117,6 +1059,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: @@ -1187,54 +1134,6 @@ WORKAROUND: 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) @@ -1261,44 +1160,95 @@ 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)) - -150: - In sbcl-0.7.1.15, compiling this code - (let* () - (flet ((wufn () (glorp table1 4.9))) - (gleep *uustk* #'wufn "#1" (list))) - (if (eql (lo foomax 3.2)) - (values) - (error "not ~S" '(eql (lo foomax 3.2)))) - (values)) - causes a failure in SB-C::ADD-TEST-CONSTRAINTS: - The value NIL is not of type SB-C::CONTINUATION. - other notes: - * The problem appears to be tied to the way that EQL is given only - one argument, and goes away when we give EQL a second argument. - * CMU CL 18c has this problem too, exercised by - (compile nil - '(lambda () - (let* () - (flet ((wufn () (glorp table1 4.9))) - (gleep *uustk* #'wufn "#1" (list))) - (if (eql (lo foomax 3.2)) - (values) - (error "not ~S" '(eql (lo foomax 3.2)))) - (values)))) +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: + (fixed in sbcl-0.7.2.9) + +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) + +162: + (reported by Robert E. Brown 2002-04-16) + When a function is called with too few arguments, causing the + debugger to be entered, the uninitialized slots in the bad call frame + seem to cause GCish problems, being interpreted as tagged data even + though they're not. In particular, executing ROOM in the + debugger at that point causes AVER failures: + * (machine-type) + "X86" + * (lisp-implementation-version) + "0.7.2.12" + * (typep 10) + ... + 0] (room) + ... + failed AVER: "(SAP= CURRENT END)" + (Christophe Rhodes reports that this doesn't occur on the SPARC, which + isn't too surprising since there are many differences in stack + implementation and GC conservatism between the X86 and other ports.) + +163: + HOST-NAMESTRING on a Unix pathname returns "Unix", which isn't + treated as a valid host by anything else in the system. (Reported by + Erik Naggum on comp.lang.lisp 2002-04-18) + +164: + The type system still can't quite deal with all useful identities; + for instance, as of sbcl-0.7.2.18, the type specifier '(and (real -1 + 7) (real 4 8)) is a HAIRY-TYPE rather than that which would be hoped + for, viz: '(real 4 7). + DEFUNCT CATEGORIES OF BUGS IR1-#: - These labels 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.