X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=36986f94e738a37d4fb4e03fbb140c445ec0ae28;hb=6c4d4d984b1af6b2a73568cec3ab9c8795cff2da;hp=369b3f7dd1a4b214cfa95155a992500178f72ed8;hpb=627c66211b93537e90c08b34b387edbd7e301011;p=sbcl.git diff --git a/BUGS b/BUGS index 369b3f7..36986f9 100644 --- a/BUGS +++ b/BUGS @@ -255,13 +255,6 @@ WORKAROUND: type safety errors reported by Peter Van Eynde July 25, 2000: 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"). @@ -271,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 @@ -429,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 @@ -615,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. @@ -635,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) @@ -652,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) @@ -676,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) @@ -721,7 +712,7 @@ WORKAROUND: T * (defclass b () ()) # - + ;;; And now... * (subtypep 'b 'a) T @@ -821,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. @@ -948,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 @@ -1123,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)) @@ -1198,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) @@ -1220,6 +1223,164 @@ WORKAROUND: 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. + 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.) + + DEFUNCT CATEGORIES OF BUGS IR1-#: These labels were used for bugs related to the old IR1 interpreter.