X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=c3ad6f924f7da9850c4f7b3480642c5e33d8cb3d;hb=c7dc5b2a1f56ed0583a0b3ea61b6ceb540c6f89e;hp=f4a9efc80c7a2f5dc548a64b2cbaa12dc151c85b;hpb=48b4e7d2121bc92ed4b4ed0951b85e764f864f05;p=sbcl.git diff --git a/BUGS b/BUGS index f4a9efc..c3ad6f9 100644 --- a/BUGS +++ b/BUGS @@ -1,4 +1,4 @@ -tREPORTING BUGS +REPORTING BUGS Bugs can be reported on the help mailing list sbcl-help@lists.sourceforge.net @@ -183,7 +183,7 @@ WORKAROUND: then executing (FOO 1.5) will cause the INTEGERP case to be selected, giving bogus output a la - exactly 1.33.. + exactly 2.5 This violates the "declarations are assertions" principle. According to the ANSI spec, in the section "System Class FUNCTION", this is a case of "lying to the compiler", but the lying is done @@ -253,44 +253,17 @@ WORKAROUND: 46: type safety errors reported by Peter Van Eynde July 25, 2000: - a: (COERCE (QUOTE (A B C)) (QUOTE (VECTOR * 4))) - => #(A B C) - In general lengths of array type specifications aren't - checked by COERCE, so it fails when the spec is - (VECTOR 4), (STRING 2), (SIMPLE-BIT-VECTOR 3), or whatever. - b: CONCATENATE has the same problem of not checking the length - of specified output array types. MAKE-SEQUENCE and MAP and - MERGE also have the same problem. c: (COERCE 'AND 'FUNCTION) returns something related to (MACRO-FUNCTION 'AND), but ANSI says it should raise an error. - h: (MAKE-CONCATENATED-STREAM (MAKE-STRING-OUTPUT-STREAM)) - should signal TYPE-ERROR. - i: MAKE-TWO-WAY-STREAM doesn't check that its arguments can - be used for input and output as needed. It should fail with - TYPE-ERROR when handed e.g. the results of - MAKE-STRING-INPUT-STREAM or MAKE-STRING-OUTPUT-STREAM in - the inappropriate positions, but doesn't. k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is not a binary input stream, but instead cheerfully reads from character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc"). 47: DEFCLASS bugs reported by Peter Van Eynde July 25, 2000: - a: (DEFCLASS FOO () (A B A)) should signal a PROGRAM-ERROR, and - doesn't. - b: (DEFCLASS FOO () (A B A) (:DEFAULT-INITARGS X A X B)) should - signal a PROGRAM-ERROR, and doesn't. - c: (DEFCLASS FOO07 NIL ((A :ALLOCATION :CLASS :ALLOCATION :CLASS))), - and other DEFCLASS forms with duplicate specifications in their - slots, should signal a PROGRAM-ERROR, and doesn't. d: (DEFGENERIC IF (X)) should signal a PROGRAM-ERROR, but instead causes a COMPILER-ERROR. -48: - SYMBOL-MACROLET bugs reported by Peter Van Eynde July 25, 2000: - c: SYMBOL-MACROLET should signal PROGRAM-ERROR if something - it binds is declared SPECIAL inside. - 51: miscellaneous errors reported by Peter Van Eynde July 25, 2000: a: (PROGN @@ -303,9 +276,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 @@ -380,35 +350,12 @@ WORKAROUND: the new output block should start indented 2 or more characters rightward of the correct location. -66: - ANSI specifies that the RESULT-TYPE argument of CONCATENATE must be - a subtype of SEQUENCE, but CONCATENATE doesn't check this properly: - (CONCATENATE 'SIMPLE-ARRAY #(1 2) '(3)) => #(1 2 3) - This also leads to funny behavior when derived type specifiers - are used, as originally reported by Milan Zamazal for CMU CL (on the - Debian bugs mailing list (?) 2000-02-27), then reported by Martin - Atzmueller for SBCL (2000-10-01 on sbcl-devel@lists.sourceforge.net): - (DEFTYPE FOO () 'SIMPLE-ARRAY) - (CONCATENATE 'FOO #(1 2) '(3)) - => # is a bad type specifier for - sequence functions. - The derived type specifier FOO should act the same way as the - built-in type SIMPLE-ARRAY here, but it doesn't. That problem - doesn't seem to exist for sequence types: - (DEFTYPE BAR () 'SIMPLE-VECTOR) - (CONCATENATE 'BAR #(1 2) '(3)) => #(1 2 3) - See also bug #46a./b., and discussion and patch sbcl-devel and - cmucl-imp 2002-07 - 67: As reported by Winton Davies on a CMU CL mailing list 2000-01-10, and reported for SBCL by Martin Atzmueller 2000-10-20: (TRACE GETHASH) crashes SBCL. In general tracing anything which is used in the implementation of TRACE is likely to have the same problem. -72: - (DECLAIM (OPTIMIZE ..)) doesn't work properly inside LOCALLY forms. - 75: As reported by Martin Atzmueller on sbcl-devel 26 Dec 2000, ANSI says that WITH-OUTPUT-TO-STRING should have a keyword @@ -435,6 +382,9 @@ WORKAROUND: LOAD-FOREIGN, and (2) hunt for any other code which uses temporary files and make it share the same new safe logic. + (partially alleviated in sbcl-0.7.9.32 by a fix by Matthew Danish to + make the temporary filename less easily guessable) + 82: Functions are assigned names based on the context in which they're defined. This is less than ideal for the functions which are @@ -467,6 +417,10 @@ WORKAROUND: (I haven't tried to investigate this bug enough to guess whether there might be any user-level symptoms.) + In fact, the type system is likely to depend on this inequality not + holding... * is not equivalent to T in many cases, such as + (VECTOR *) /= (VECTOR T). + 94a: Inconsistencies between derived and declared VALUES return types for DEFUN aren't checked very well. E.g. the logic which successfully @@ -545,18 +499,6 @@ WORKAROUND: the first time around, until regression tests are written I'm not comfortable merging the patches in the CVS version of SBCL. -104: - (DESCRIBE 'SB-ALIEN:DEF-ALIEN-TYPE) reports the macro argument list - incorrectly: - DEF-ALIEN-TYPE is - an external symbol - in #. - Macro-function: # - Macro arguments: (#:whole-470 #:environment-471) - On Sat, May 26, 2001 09:45:57 AM CDT it was compiled from: - /usr/stuff/sbcl/src/code/host-alieneval.lisp - Created: Monday, March 12, 2001 07:47:43 AM CST - 108: (TIME (ROOM T)) reports more than 200 Mbytes consed even for a clean, just-started SBCL system. And it seems to be right: @@ -564,43 +506,6 @@ WORKAROUND: time trying to GC afterwards. Surely there's some more economical way to implement (ROOM T). -110: - reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs - collection: - ;;; The compiler is flushing the argument type test, and the default - ;;; case in the cond, so that calling with say a fixnum 0 causes a - ;;; SIGBUS. - (declaim (optimize (safety 2) (speed 3))) - (defun tst (x) - (declare (type (or string stream) x)) - (cond ((typep x 'string) 'string) - ((typep x 'stream) 'stream) - (t - 'none))) - The symptom in sbcl-0.6.12.42 on OpenBSD is actually (TST 0)=>STREAM - (not the SIGBUS reported in the comment) but that's broken too; - type declarations are supposed to be treated as assertions unless - SAFETY 0, so we should be getting a TYPE-ERROR. - -113: - reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs - collection: - (in-package :cl-user) - ;;; From: David Gadbois - ;;; - ;;; Logical pathnames aren't externalizable. - ;;; Test case: - (let ((tempfile "/tmp/test.lisp")) - (setf (logical-pathname-translations "XXX") - '(("XXX:**;*.*" "/tmp/**/*.*"))) - (with-open-file (out tempfile :direction :output) - (write-string "(defvar *path* #P\"XXX:XXX;FOO.LISP\")" out)) - (compile-file tempfile)) - The error message in sbcl-0.6.12.42 is - ; caught ERROR: - ; (while making load form for #) - ; A logical host can't be dumped as a constant: # - 115: reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs collection: @@ -617,6 +522,40 @@ WORKAROUND: internal error, failed AVER: "(COMMON-LISP:EQ (SB!C::TN-ENVIRONMENT SB!C:TN) SB!C::TN-ENV)" + This examples better illustrates the problem: + + (defun tst () + (declare (optimize (speed 2) (debug 3))) + (flet ((m1 () + (bar (if (foo) 1 2)) + (let ((x (foo))) + (bar x (list x))))) + (if (catch nil) + (m1) + (m1)))) + + (X is allocated in the physical environment of M1; X is :WRITE in + the call of LET [convert-to-global]; IF makes sure that a block + exists in M1 before this call.) + + Because X is :DEBUG-ENVIRONMENT, it is :LIVE by default in all + blocks in the environment, particularly it is :LIVE in the start of + M1 (where it is not yet :WRITE) [setup-environment-tn-conflicts]. + + Then :LIVE is propagated backwards, i.e. into the caller of M1 + where X does not exist [lifetime-flow-analysis]. + + (CATCH NIL) causes all TNs to be saved; Python fails on saving + non-existent variable; if it is replaced with (FOO), the problem + appears when debugging TST: LIST-LOCALS says + + debugger invoked on condition of type SB-DI:UNKNOWN-DEBUG-VAR: + + # is not in #. + + (in those old versions, in which debugger worked :-(). + 117: When the compiler inline expands functions, it may be that different kinds of return values are generated from different code branches. @@ -659,19 +598,6 @@ WORKAROUND: Raymond Toy comments that this is tricky on the X86 since its FPU uses 80-bit precision internally. -120a: - The compiler incorrectly figures the return type of - (DEFUN FOO (FRAME UP-FRAME) - (IF (OR (NOT FRAME) - T) - FRAME - "BAR")) - as NIL. - - This problem exists in CMU CL 18c too. When I reported it on - cmucl-imp@cons.org, Raymond Toy replied 23 Aug 2001 with - a partial explanation, but no fix has been found yet. - 120b: Even in sbcl-0.pre7.x, which is supposed to be free of the old non-ANSI behavior of treating the function return type inferred @@ -680,32 +606,14 @@ WORKAROUND: is attached to FOO in 120a above, and used to optimize code which calls FOO. -122: - There was some sort of screwup in handling of - (IF (NOT (IGNORE-ERRORS ..))). E.g. - (defun foo1i () - (if (not (ignore-errors - (make-pathname :host "foo" :directory "!bla" :name "bar"))) - (print "ok") - (error "notunlessnot"))) - The (NOT (IGNORE-ERRORS ..)) form evaluates to T, so this should be - printing "ok", but instead it's going to the ERROR. This problem - seems to've been introduced by MNA's HANDLER-CASE patch (sbcl-devel - 2001-07-17) and as a workaround (put in sbcl-0.pre7.14.flaky4.12) - I reverted back to the old weird HANDLER-CASE code. However, I - think the problem looks like a compiler bug in handling RETURN-FROM, - so I left the MNA-patched code in HANDLER-CASE (suppressed with - #+NIL) and I'd like to go back to see whether this really is - a compiler bug before I delete this BUGS entry. - 124: As of version 0.pre7.14, SBCL's implementation of MACROLET makes the entire lexical environment at the point of MACROLET available - in the bodies of the macroexpander functions. In particular, it - allows the function bodies (which run at compile time) to try to + in the bodies of the macroexpander functions. In particular, it + allows the function bodies (which run at compile time) to try to access lexical variables (which are only defined at runtime). It doesn't even issue a warning, which is bad. - + The SBCL behavior arguably conforms to the ANSI spec (since the spec says that the behavior is undefined, ergo anything conforms). However, it would be better to issue a compile-time error. @@ -721,7 +629,7 @@ WORKAROUND: the local macro definitions in a MACROLET, but the consequences are undefined if the local macro definitions reference any local variable or function bindings that are visible in that - lexical environment. + lexical environment. Then it seems to contradict itself by giving the example (defun foo (x flag) (macrolet ((fudge (z) @@ -738,6 +646,12 @@ WORKAROUND: but actual specification quoted above says that the actual behavior is undefined. + (Since 0.7.8.23 macroexpanders are defined in a restricted version + of the lexical environment, containing no lexical variables and + functions, which seems to conform to ANSI and CLtL2, but signalling + a STYLE-WARNING for references to variables similar to locals might + be a good thing.) + 125: (as reported by Gabe Garza on cmucl-help 2001-09-21) (defvar *tmp* 3) @@ -762,120 +676,15 @@ WORKAROUND: structure classes related by inheritance. As of 0.7.0, SBCL still doesn't follow it. -129: - insufficient syntax checking in MACROLET: - (defun foo (x) - (macrolet ((defmacro bar (z) `(+ z z))) - (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, + FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However, at least as of sbcl-0.7.0, this isn't the case. Information about FDEFINITIONs and PROCLAIMed properties is stored in globaldb.lisp essentially in ordinary (non-weak) hash tables keyed by symbols. Thus, once a system has an entry in this system, it tends to live forever, even when it is uninterned and all other references to it - are lost. - -136: - (reported by Arnaud Rouanet on cmucl-imp 2001-12-18) - (defmethod foo ((x integer)) - x) - (defmethod foo :around ((x integer)) - (let ((x (1+ x))) - (call-next-method))) - Now (FOO 3) should return 3, but instead it returns 4. - -140: - (reported by Alexey Dejneka sbcl-devel 2002-01-03) - - SUBTYPEP does not work well with redefined classes: - --- - * (defclass a () ()) - # - * (defclass b () ()) - # - * (subtypep 'b 'a) - NIL - T - * (defclass b (a) ()) - # - * (subtypep 'b 'a) - T - T - * (defclass b () ()) - # - - ;;; And now... - * (subtypep 'b 'a) - T - T - - This bug was fixed in sbcl-0.7.4.1 by invalidating the PCL wrapper - class upon redefinition. Unfortunately, doing so causes bug #176 to - appear. Pending further investication, one or other of these bugs - might be present at any given time. + are lost. 141: Pretty-printing nested backquotes doesn't work right, as @@ -885,12 +694,6 @@ WORKAROUND: * (lisp-implementation-version) "0.pre7.129" -142: - (as reported by Lynn Quam on cmucl-imp ca. 2002-01-16) - %NATURALIZE-C-STRING conses a lot, like 16 bytes per byte - of the naturalized string. We could probably port the patches - from the cmucl-imp mailing list. - 143: (reported by Jesse Bouwman 2001-10-24 through the unfortunately prominent SourceForge web/db bug tracking system, which is @@ -972,27 +775,14 @@ WORKAROUND: 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 + 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. + (Python LET-converts KIDIFY1 into KID-FROB, then tries to inline + expand KID-FROB into %ZEEP. Having partially done it, it sees a call + of KIDIFY1, which already does not exist. So it gives up on + expansion, leaving garbage consisting of infinished blocks of the + partially converted function.) 157: Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and @@ -1019,31 +809,6 @@ WORKAROUND: isn't too surprising since there are many differences in stack implementation and GC conservatism between the X86 and other ports.) -166: - Compiling - (in-package :cl-user) - (defstruct uustk) - (defmethod permanentize ((uustk uustk)) - (flet ((frob (hash-table test-for-deletion) - ) - (obj-entry.stale? (oe) - (destructuring-bind (key . datum) oe - (declare (type simple-vector key)) - (deny0 (void? datum)) - (some #'stale? key)))) - (declare (inline frob obj-entry.stale?)) - (frob (uustk.args-hash->obj-alist uustk) - #'obj-entry.stale?) - (frob (uustk.hash->memoized-objs-list uustk) - #'objs.stale?)) - (call-next-method)) - in sbcl-0.7.3.11 causes an assertion failure, - failed AVER: - "(NOT -(AND (NULL (BLOCK-SUCC B)) - (NOT (BLOCK-DELETE-P B)) - (NOT (EQ B (COMPONENT-HEAD #)))))" - 167: In sbcl-0.7.3.11, compiling the (illegal) code (in-package :cl-user) @@ -1058,31 +823,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. - -171: - (reported by Pierre Mai while investigating bug 47): - (DEFCLASS FOO () ((A :SILLY T))) - signals a SIMPLE-ERROR, not a PROGRAM-ERROR. - -172: - sbcl's treatment of at least macro lambda lists is too permissive; - e.g., in sbcl-0.7.3.7: - (defmacro foo (&rest rest bar) `(,bar ,rest)) - (macroexpand '(foo quux zot)) -> (QUUX (QUUX ZOT)) - whereas section 3.4.4 of the CLHS doesn't allow required parameters - to come after the rest argument. - 173: The compiler sometimes tries to constant-fold expressions before it checks to see whether they can be reached. This can lead to @@ -1098,74 +838,18 @@ WORKAROUND: code. Since then the warning has been downgraded to STYLE-WARNING, so it's still a bug but at least it's a little less annoying. -174: - The error message from attempting to use a #\Return format - directive: - (format nil "~^M") ; replace "^M" with a literal #\Return - debugger invoked on condition of type SB-FORMAT::FORMAT-ERROR: - error in format: unknown format directive - ~ - ^ - is not terribly helpful; this is more noticeable than parallel cases - with e.g. #\Backspace because of the differing newline conventions - on various operating systems. (reported by Harald Hanche-Olsen on - cmucl-help 2002-05-31) - -176: - reported by Alexey Dejneka 08 Jun 2002 in sbcl-devel: - Playing with McCLIM, I've received an error "Unbound variable WRAPPER - in SB-PCL::CHECK-WRAPPER-VALIDITY". - (defun check-wrapper-validity (instance) - (let* ((owrapper (wrapper-of instance))) - (if (not (invalid-wrapper-p owrapper)) - owrapper - (let* ((state (wrapper-state wrapper)) ; !!! - ... - I've tried to replace it with OWRAPPER, but now OBSOLETE-INSTANCE-TRAP - breaks with "NIL is not of type SB-KERNEL:LAYOUT". - SBCL 0.7.4.13. - partial fix: The undefined variable WRAPPER resulted from an error - in recent refactoring, as can be seen by comparing to the code in e.g. - sbcl-0.7.2. Replacing WRAPPER with OWRAPPER (done by WHN in sbcl-0.7.4.22) - should bring the code back to its behavior as of sbcl-0.7.2, but - that still leaves the OBSOLETE-INSTANCE-TRAP bug. An example of - input which triggers that bug is - (dotimes (i 20) - (let ((lastname (intern (format nil "C~D" (1- i)))) - (name (intern (format nil "C~D" i)))) - (eval `(defclass ,name - (,@(if (= i 0) nil (list lastname))) - ())) - (eval `(defmethod initialize-instance :after ((x ,name) &rest any) - (declare (ignore any)))))) - (defclass b () ()) - (defclass c0 (b) ()) - (make-instance 'c19) - - See also bug #140. - 178: "AVER failure compiling confused THEs in FUNCALL" In sbcl-0.7.4.24, compiling (defun bug178 (x) (funcall (the function (the standard-object x)))) - gives + gives failed AVER: "(AND (EQ (IR2-CONTINUATION-PRIMITIVE-TYPE 2CONT) FUNCTION-PTYPE) (EQ CHECK T))" This variant compiles OK, though: (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. + (since 0.7.8.9 it does not signal an error; see also bug 199) 183: "IEEE floating point issues" Even where floating point handling is being dealt with relatively @@ -1192,14 +876,6 @@ WORKAROUND: :ACCRUED-EXCEPTIONS (:INEXACT) :FAST-MODE NIL) -185: "top-level forms at the REPL" - * (locally (defstruct foo (a 0 :type fixnum))) - gives an error: - ; caught ERROR: - ; (in macroexpansion of (SB-KERNEL::%DELAYED-GET-COMPILER-LAYOUT BAR)) - however, compiling and loading the same expression in a file works - as expected. - 187: "type inference confusion around DEFTRANSFORM time" (reported even more verbosely on sbcl-devel 2002-06-28 as "strange bug in DEFTRANSFORM") @@ -1312,9 +988,366 @@ WORKAROUND: results in a STYLE-WARNING: undefined-function SB-SLOT-ACCESSOR-NAME::|COMMON-LISP-USER A-CLASS-X slot READER| + + APD's fix for this was checked in to sbcl-0.7.6.20, but Pierre + Mai points out that the declamation of functions is in fact + incorrect in some cases (most notably for structure + classes). This means that at present erroneous attempts to use + WITH-SLOTS and the like on classes with metaclass STRUCTURE-CLASS + won't get the corresponding STYLE-WARNING. c. the examples in CLHS 7.6.5.1 (regarding generic function lambda lists and &KEY arguments) do not signal errors when they should. +192: "Python treats free type declarations as promises." + b. What seemed like the same fundamental problem as bug 192a, but + was not fixed by the same (APD "more strict type checking + sbcl-devel 2002-08-97) patch: + (DOTIMES (I ...) (DOTIMES (J ...) (DECLARE ...) ...)): + (declaim (optimize (speed 1) (safety 3))) + (defun trust-assertion (i) + (dotimes (j i) + (declare (type (mod 4) i)) ; when commented out, behavior changes! + (unless (< i 5) + (print j)))) + (trust-assertion 6) ; prints nothing unless DECLARE is commented out + + (see bug 203) + +194: "no error from (THE REAL '(1 2 3)) in some cases" + fixed parts: + a. In sbcl-0.7.7.9, + (multiple-value-prog1 (progn (the real '(1 2 3)))) + returns (1 2 3) instead of signalling an error. This was fixed by + APD's "more strict type checking patch", but although the fixed + code (in sbcl-0.7.7.19) works (signals TYPE-ERROR) interactively, + it's difficult to write a regression test for it, because + (IGNORE-ERRORS (MULTIPLE-VALUE-PROG1 (PROGN (THE REAL '(1 2 3))))) + still returns (1 2 3). + still-broken parts: + b. (IGNORE-ERRORS (MULTIPLE-VALUE-PROG1 (PROGN (THE REAL '(1 2 3))))) + returns (1 2 3). (As above, this shows up when writing regression + tests for fixed-ness of part a.) + c. Also in sbcl-0.7.7.9, (IGNORE-ERRORS (THE REAL '(1 2 3))) => (1 2 3). + d. At the REPL, + (null (ignore-errors + (let ((arg1 1) + (arg2 (identity (the real #(1 2 3))))) + (if (< arg1 arg2) arg1 arg2)))) + => T + but putting the same expression inside (DEFUN FOO () ...), + (FOO) => NIL. + notes: + * Actually this entry is probably multiple bugs, as + Alexey Dejneka commented on sbcl-devel 2002-09-03:) + I don't think that placing these two bugs in one entry is + a good idea: they have different explanations. The second + (min 1 nil) is caused by flushing of unused code--IDENTITY + can do nothing with it. So it is really bug 122. The first + (min nil) is due to M-V-PROG1: substituting a continuation + for the result, it forgets about type assertion. The purpose + of IDENTITY is to save the restricted continuation from + inaccurate transformations. + * Alexey Dejneka pointed out that + (IGNORE-ERRORS (IDENTITY (THE REAL '(1 2 3)))) + works as it should. Also + (IGNORE-ERRORS (VALUES (THE REAL '(1 2 3)))) + works as it should. Perhaps this is another case of VALUES type + intersections behaving in non-useful ways? + +199: "hairy FUNCTION types confuse the compiler" + (reported by APD sbcl-devel 2002-09-15) + (DEFUN MUR (F) + (EQ NIL (FUNCALL F))) + + (DEFUN FOO (F X) + (DECLARE (TYPE (AND FUNCTION (SATISFIES MUR)) F)) + (FUNCALL F X)) + + fails to compile, printing + failed AVER: + "(AND (EQ (IR2-CONTINUATION-PRIMITIVE-TYPE 2CONT) FUNCTION-PTYPE) (EQ CHECK T))" + + APD further reports that this bug is not present in CMUCL. + + (this case was fixed in 0.7.8.9; see also bug 178) + +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" + +203: + Compiler does not check THEs on unused values, e.g. in + + (progn (the real (list 1)) t) + + This situation may appear during optimizing away degenerate cases of + certain functions: see bugs 54, 192b. + +205: "environment issues in cross compiler" + (These bugs have no impact on user code, but should be fixed or + documented.) + a. Macroexpanders introduced with MACROLET are defined in the null + lexical environment. + b. The body of (EVAL-WHEN (:COMPILE-TOPLEVEL) ...) is evaluated in + the null lexical environment. + +206: ":SB-FLUID feature broken" + (reported by Antonio Martinez-Shotton sbcl-devel 2002-10-07) + Enabling :SB-FLUID in the target-features list in sbcl-0.7.8 breaks + the build. + +207: "poorly distributed SXHASH results for compound data" + SBCL's SXHASH could probably try a little harder. ANSI: "the + intent is that an implementation should make a good-faith + effort to produce hash-codes that are well distributed + within the range of non-negative fixnums". But + (let ((hits (make-hash-table))) + (dotimes (i 16) + (dotimes (j 16) + (let* ((ij (cons i j)) + (newlist (push ij (gethash (sxhash ij) hits)))) + (when (cdr newlist) + (format t "~&collision: ~S~%" newlist)))))) + reports lots of collisions in sbcl-0.7.8. A stronger MIX function + would be an obvious way of fix. Maybe it would be acceptably efficient + to redo MIX using a lookup into a 256-entry s-box containing + 29-bit pseudorandom numbers? + +208: "package confusion in PCL handling of structure slot handlers" + In sbcl-0.7.8 compiling and loading + (in-package :cl) + (defstruct foo (slot (error "missing")) :type list :read-only t) + (defmethod print-object ((foo foo) stream) (print nil stream)) + causes CERROR "attempting to modify a symbol in the COMMON-LISP + package: FOO-SLOT". (This is fairly bad code, but still it's hard + to see that it should cause symbols to be interned in the CL package.) + +211: "keywords processing" + a. :ALLOW-OTHER-KEYS T should allow a function to receive an odd + number of keyword arguments. + e. Compiling + + (flet ((foo (&key y) (list y))) + (list (foo :y 1 :y 2))) + + issues confusing message + + ; in: LAMBDA NIL + ; (FOO :Y 1 :Y 2) + ; + ; caught STYLE-WARNING: + ; The variable #:G15 is defined but never used. + +212: "Sequence functions and circular arguments" + COERCE, MERGE and CONCATENATE go into an infinite loop when given + circular arguments; it would be good for the user if they could be + given an error instead (ANSI 17.1.1 allows this behaviour on the part + of the implementation, as conforming code cannot give non-proper + sequences to these functions. MAP also has this problem (and + solution), though arguably the convenience of being able to do + (MAP 'LIST '+ FOO '#1=(1 . #1#)) + might be classed as more important (though signalling an error when + all of the arguments are circular is probably desireable). + +213: "Sequence functions and type checking" + a. MAKE-SEQUENCE, COERCE, MERGE and CONCATENATE cannot deal with + various complicated, though recognizeable, CONS types [e.g. + (CONS * (CONS * NULL)) + which according to ANSI should be recognized] (and, in SAFETY 3 + code, should return a list of LENGTH 2 or signal an error) + b. MAP, when given a type argument that is SUBTYPEP LIST, does not + check that it will return a sequence of the given type. Fixing + it along the same lines as the others (cf. work done around + sbcl-0.7.8.45) is possible, but doing so efficiently didn't look + entirely straightforward. + c. All of these functions will silently accept a type of the form + (CONS INTEGER *) + whether or not the return value is of this type. This is + probably permitted by ANSI (see "Exceptional Situations" under + ANSI MAKE-SEQUENCE), but the DERIVE-TYPE mechanism does not + know about this escape clause, so code of the form + (INTEGERP (CAR (MAKE-SEQUENCE '(CONS INTEGER *) 2))) + can erroneously return T. + +214: + SBCL 0.6.12.43 fails to compile + + (locally + (declare (optimize (inhibit-warnings 0) (compilation-speed 2))) + (flet ((foo (&key (x :vx x-p)) (list x x-p))) + (foo 1 2))) + + or a more simple example: + + (locally + (declare (optimize (inhibit-warnings 0) (compilation-speed 2))) + (lambda (x) (declare (fixnum x)) (if (< x 0) 0 (1- x)))) + +215: ":TEST-NOT handling by functions" + a. FIND and POSITION currently signal errors when given non-NIL for + both their :TEST and (deprecated) :TEST-NOT arguments, but by + ANSI 17.2 "the consequences are unspecified", which by ANSI 1.4.2 + means that the effect is "unpredictable but harmless". It's not + clear what that actually means; it may preclude conforming + implementations from signalling errors. + b. COUNT, REMOVE and the like give priority to a :TEST-NOT argument + when conflict occurs. As a quality of implementation issue, it + might be preferable to treat :TEST and :TEST-NOT as being in some + sense the same &KEY, and effectively take the first test function in + the argument list. + c. Again, a quality of implementation issue: it would be good to issue a + STYLE-WARNING at compile-time for calls with :TEST-NOT, and a + WARNING for calls with both :TEST and :TEST-NOT; possibly this + latter should be WARNed about at execute-time too. + +216: "debugger confused by frames with invalid number of arguments" + In sbcl-0.7.8.51, executing e.g. (VECTOR-PUSH-EXTEND T), BACKTRACE, Q + leaves the system confused, enough so that (QUIT) no longer works. + It's as though the process of working with the uninitialized slot in + the bad VECTOR-PUSH-EXTEND frame causes GC problems, though that may + not be the actual problem. (CMU CL 18c doesn't have problems with this.) + +217: "Bad type operations with FUNCTION types" + In sbcl.0.7.7: + + * (values-type-union (specifier-type '(function (base-char))) + (specifier-type '(function (integer)))) + + # + + It causes insertion of wrong type assertions into generated + code. E.g. + + (defun foo (x s) + (let ((f (etypecase x + (character #'write-char) + (integer #'write-byte)))) + (funcall f x s) + (etypecase x + (character (write-char x s)) + (integer (write-byte x s))))) + + Then (FOO #\1 *STANDARD-OUTPUT*) signals type error. + + (In 0.7.9.1 the result type is (FUNCTION * *), so Python does not + produce invalid code, but type checking is not accurate. Similar + problems exist with VALUES-TYPE-INTERSECTION.) + +218: "VALUES type specifier semantics" + (THE (VALUES ...) ...) in safe code discards extra values. + + (defun test (x y) (the (values integer) (truncate x y))) + (test 10 4) => 2 + +219: "DEFINE-COMPILER-MACRO in non-toplevel contexts evaluated at compile-time" + In sbcl-0.7.9: + + * (defun foo (x) + (when x + (define-compiler-macro bar (&whole whole) + (declare (ignore whole)) + (print "expanding compiler macro") + 1))) + FOO + * (defun baz (x) (bar)) + [ ... ] + "expanding compiler macro" + BAZ + * (baz t) + 1 + +220: + Sbcl 0.7.9 fails to compile + + (multiple-value-call #'list + (the integer (helper)) + nil) + + Type check for INTEGER is inserted, the result of which serves as + the first argument of M-V-C, is inserted after evaluation of NIL. So + arguments of M-V-C are pushed in the wrong order. As a temporary + workaround type checking was disabled for M-V-Cs in 0.7.9.13. A + better solution would be to put a check between evaluation of + arguments, but it could be tricky to check result types of PROG1, IF + etc. + +222: "environment problems in PCL" + Evaluating + + (symbol-macrolet ((x 1)) + (defmethod foo (z) + (macrolet ((ml (form) `(progn ,form ,x))) + (ml (print x))))) + + causes + + debugger invoked on condition of type UNBOUND-VARIABLE: + The variable X is unbound. + +223: "(SETF FDEFINITION) and #' semantics broken for wrappers" + Although this + (defun foo (x) + (print x)) + (defun traced (fn) + (lambda (&rest rest) + (format t "~&about to call ~S on ~S~%" fn rest) + (apply fn rest) + (format t "~&returned from ~S~%" fn))) + (setf (fdefinition 'foo) + (traced #'foo)) + (foo 11) + does what one would expect, this + (defun bar (x) + (print x)) + (let ((bar0 #'bar)) + (setf (fdefinition 'bar) + (lambda (&rest rest) + (format t "~&about to enter BAR ~S~%" rest) + (apply bar0 rest) + (format t "~&back from BAR~%")))) + (bar 12) + recurses endlessly in sbcl-0.7.9.32. (Or it works if #' and + FDEFINITION are replaced by SYMBOL-FUNCTION.) + +224: + SBCL 0.7.8 fails to compile + + (localy (declare (optimize (safety 3))) + (ignore-errors (progn (values-list (car (list '(1 . 2)))) t))) + +225: + (fixed in 0.7.9.42) + +226: "AVER failure in COMPILE-FILE of clocc-ansi-test/tests.lisp" + sbcl-0.7.9.43 dies with failed AVER "(EQ (TN-PHYSENV TN) TN-ENV)" when + trying to compile clocc-ansi-test/tests.lisp. sbcl-0.7.9.31 was able to + to compile it. A smaller test case exhibiting the same problem is + (declaim (optimize (speed 0) (safety 3) (debug 3))) + (defun c-a-p () + (flet ((safe-format (stream string &rest r) + (unless (ignore-errors (progn + (apply #'format stream string r) + t)) + (format stream "~&foo ~S" string)))) + (cond + ((eq my-result :ERROR) + (cond + ((ignore-errors (typep condition result)) + (safe-format t "~&bar ~S" result)) + (t + (safe-format t "~&baz ~S (~A) ~S" condition condition result))))))) + + DEFUNCT CATEGORIES OF BUGS IR1-#: These labels were used for bugs related to the old IR1 interpreter.