X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=d6d3cd72436d500a28d54961b198f330f9af91b4;hb=3eb39e017e52b5d704e7d33405c873af52a533fd;hp=c66439053aa5d7387bd7519b44ba36b39950aa3d;hpb=c831b2828176641e93a45d3fd643e9f58cd44a3f;p=sbcl.git diff --git a/BUGS b/BUGS index c664390..d6d3cd7 100644 --- a/BUGS +++ b/BUGS @@ -264,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 @@ -984,14 +979,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") @@ -1236,6 +1223,178 @@ WORKAROUND: 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.) + +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 + DEFUNCT CATEGORIES OF BUGS IR1-#: These labels were used for bugs related to the old IR1 interpreter.