X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=04f8dca856a9fd47a70bbd2a5f9ac4e7d60d173d;hb=4372fa18426aa89379563bcbf61941317c93fce0;hp=de90432424d34e54a95b3985faea9607e00cff95;hpb=3c76429562383ac91cec4880b7b86234362e1ed4;p=sbcl.git diff --git a/BUGS b/BUGS index de90432..04f8dca 100644 --- a/BUGS +++ b/BUGS @@ -253,23 +253,8 @@ 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"). @@ -279,11 +264,6 @@ WORKAROUND: 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 @@ -370,26 +350,6 @@ 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) @@ -457,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 @@ -643,11 +607,11 @@ WORKAROUND: 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. @@ -663,7 +627,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) @@ -680,6 +644,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) @@ -704,22 +674,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). - 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. + are lost. 136: (reported by Arnaud Rouanet on cmucl-imp 2001-12-18) @@ -749,7 +712,7 @@ WORKAROUND: T * (defclass b () ()) # - + ;;; And now... * (subtypep 'b 'a) T @@ -849,9 +812,15 @@ 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. + (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 UPGRADED-COMPLEX-PART-TYPE should have an optional environment argument. @@ -976,13 +945,15 @@ WORKAROUND: 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))) + (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 well (as of sbcl-0.7.5, on sparc/sunos and alpha; see bug #146), the @@ -1151,6 +1122,8 @@ WORKAROUND: (print j)))) (trust-assertion 6) ; prints nothing unless DECLARE is commented out + (see bug 203) + 193: "unhelpful CLOS error reporting when the primary method is missing" In sbcl-0.7.7, when (defmethod foo :before ((x t)) (print x)) @@ -1226,6 +1199,8 @@ WORKAROUND: 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) @@ -1240,27 +1215,96 @@ WORKAROUND: (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*.) +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.) + +209: "DOCUMENTATION generic function has wrong argument precedence order" + (fixed in sbcl-0.7.8.39) + +210: "unsafe evaluation of DEFSTRUCT slot initforms in BOA constructors" + (fixed in sbcl-0.7.8.35) + +211: "keywords processing" + a. :ALLOW-OTHER-KEYS T should allow a function to receive an odd + number of keyword arguments. + b. Compiling of a local call with an unknown key and + :ALLOW-OTHER-KEYS T should not cause a WARNING. + c. Compiler should not warn on an unknown key :ALLOW-OTHER-KEYS. + +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. DEFUNCT CATEGORIES OF BUGS IR1-#: