X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=b849dad7e12ff677fd5f22193c7d2c586c277439;hb=683874b497a99cd2c11b6c5d9b47e2785b1ede5f;hp=f43acb1cc767413dc2f2926c2bc4b69acd0b6aa2;hpb=7c07a6f965c51828d8f452b47e0620d8e6cf2959;p=sbcl.git diff --git a/BUGS b/BUGS index f43acb1..b849dad 100644 --- a/BUGS +++ b/BUGS @@ -88,9 +88,9 @@ WORKAROUND: to really grok function declarations. 7: - The "byte compiling top-level form:" output ought to be condensed. + The "compiling top-level form:" output ought to be condensed. Perhaps any number of such consecutive lines ought to turn into a - single "byte compiling top-level forms:" line. + single "compiling top-level forms:" line. 10: The way that the compiler munges types with arguments together @@ -243,7 +243,8 @@ WORKAROUND: E.g. compiling and loading (DECLAIM (OPTIMIZE (SAFETY 3))) (DEFUN FACTORIAL (X) (GAMMA (1+ X))) - (DECLAIM (FTYPE (FUNCTION (UNSIGNED-BYTE) FACTORIAL))) + (DEFUN GAMMA (X) X) + (DECLAIM (FTYPE (FUNCTION (UNSIGNED-BYTE)) FACTORIAL)) (DEFUN FOO (X) (COND ((> (FACTORIAL X) 1.0E6) (FORMAT T "too big~%")) @@ -386,18 +387,6 @@ WORKAROUND: c: SYMBOL-MACROLET should signal PROGRAM-ERROR if something it binds is declared SPECIAL inside. -49: - LOOP bugs reported by Peter Van Eynde July 25, 2000: - a: (LOOP WITH (A B) DO (PRINT 1)) is a syntax error according to - the definition of WITH clauses given in the ANSI spec, but - compiles and runs happily in SBCL. - b: a messy one involving package iteration: -interpreted Form: (LET ((PACKAGE (MAKE-PACKAGE "LOOP-TEST"))) (INTERN "blah" PACKAGE) (LET ((BLAH2 (INTERN "blah2" PACKAGE))) (EXPORT BLAH2 PACKAGE)) (LIST (SORT (LOOP FOR SYM BEING EACH PRESENT-SYMBOL OF PACKAGE FOR SYM-NAME = (SYMBOL-NAME SYM) COLLECT SYM-NAME) (FUNCTION STRING<)) (SORT (LOOP FOR SYM BEING EACH EXTERNAL-SYMBOL OF PACKAGE FOR SYM-NAME = (SYMBOL-NAME SYM) COLLECT SYM-NAME) (FUNCTION STRING<)))) -Should be: (("blah" "blah2") ("blah2")) -SBCL: (("blah") ("blah2")) - * (LET ((X 1)) (LOOP FOR I BY (INCF X) FROM X TO 10 COLLECT I)) - doesn't work -- SBCL's LOOP says BY isn't allowed in a FOR clause. - 50: type system errors reported by Peter Van Eynde July 25, 2000: a: (SUBTYPEP 'BIGNUM 'INTEGER) => NIL, NIL @@ -708,17 +697,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: 80: (fixed early Feb 2001 by MNA) -81: - As reported by wbuss@TELDA.NET (Wolfhard Buss) on cmucl-help - 2001-02-14, - According to CLHS - (loop with (a . b) of-type float = '(0.0 . 1.0) - and (c . d) of-type float = '(2.0 . 3.0) - return (list a b c d)) - should evaluate to (0.0 1.0 2.0 3.0). cmucl-18c disagrees and - invokes the debugger: "B is not of type list". - SBCL does the same thing. - 82: Functions are assigned names based on the context in which they're defined. This is less than ideal for the functions which are @@ -1039,21 +1017,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: ; (while making load form for #) ; A logical host can't be dumped as a constant: # -114: - reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs - collection: - (in-package :cl-user) - ;;; This file causes the byte compiler to fail. - (declaim (optimize (speed 0) (safety 1))) - (defun tst1 () - (values - (multiple-value-list - (catch 'a - (return-from tst1))))) - The error message in sbcl-0.6.12.42 is - internal error, failed AVER: - "(COMMON-LISP:EQUAL (SB!C::BYTE-BLOCK-INFO-START-STACK SB!INT:INFO) SB!C::STACK)" - 115: reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs collection: @@ -1112,65 +1075,318 @@ Error in function C::GET-LAMBDA-TO-COMPILE: 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 + from the current function definition as a declaration of the + return type from any function of that name, the return type of NIL + 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. + +123: + The *USE-IMPLEMENTATION-TYPES* hack causes bugs, particularly + (IN-PACKAGE :SB-KERNEL) + (TYPE= (SPECIFIER-TYPE '(VECTOR T)) + (SPECIFIER-TYPE '(VECTOR UNDEFTYPE))) + Then because of this, the compiler bogusly optimizes + (TYPEP #(11) '(SIMPLE-ARRAY UNDEF-TYPE 1)) + to T. Unfortunately, just setting *USE-IMPLEMENTATION-TYPES* to + NIL around sbcl-0.pre7.14.flaky4.12 didn't work: the compiler complained + about type mismatches (probably harmlessly, another instance of bug 117); + and then cold init died with a segmentation fault. + +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 + 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. + Unfortunately I (WHN) don't see any simple way to detect this + condition in order to issue such an error, so for the meantime + SBCL just does this weird broken "conforming" thing. + + The ANSI standard says, in the definition of the special operator + MACROLET, + The macro-expansion functions defined by MACROLET are defined + in the lexical environment in which the MACROLET form appears. + Declarations and MACROLET and SYMBOL-MACROLET definitions affect + 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. + Then it seems to contradict itself by giving the example + (defun foo (x flag) + (macrolet ((fudge (z) + ;The parameters x and flag are not accessible + ; at this point; a reference to flag would be to + ; the global variable of that name. + ` (if flag (* ,z ,z) ,z))) + ;The parameters x and flag are accessible here. + (+ x + (fudge x) + (fudge (+ x 1))))) + The comment "a reference to flag would be to the global variable + of the same name" sounds like good behavior for the system to have. + but actual specification quoted above says that the actual behavior + is undefined. + +125: + (as reported by Gabe Garza on cmucl-help 2001-09-21) + (defvar *tmp* 3) + (defun test-pred (x y) + (eq x y)) + (defun test-case () + (let* ((x *tmp*) + (func (lambda () x))) + (print (eq func func)) + (print (test-pred func func)) + (delete func (list func)))) + Now calling (TEST-CASE) gives output + NIL + NIL + (#) + Evidently Python thinks of the lambda as a code transformation so + much that it forgets that it's also an object. + +126: + (fixed in 0.pre7.41) + +127: + The DEFSTRUCT section of the ANSI spec, in the :CONC-NAME section, + specifies a precedence rule for name collisions between slot accessors of + structure classes related by inheritance. As of 0.7.0, SBCL still + doesn't follow it. + +128: + READ-SEQUENCE doesn't work for Gray streams. (reported by Nathan + Froyd sbcl-devel 2001-10-15) As per subsequent discussion on the + list, the Gray streams proposal doesn't mention READ-SEQUENCE and + WRITE-SEQUENCE because it predates them, generalizing it to + cover them is an obvious extension, ACL does it, and there's a + patch for for CMU CL which does it too. + +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). + +130: + reported by Alexey Dejneka on sbcl-devel 2001-11-03 + (defun x (x) + "Return X if X is a non-negative integer." + (let ((step (lambda (%funcall) + (lambda (n) + (cond ((= n 0) 0) + (t (1+ (funcall %funcall (1- n))))))))) + (funcall + ((lambda (a) + (funcall step (lambda (n) + (funcall (funcall a a) n)))) + (lambda (a) + (funcall step (lambda (n) + (funcall (funcall a a) n))))) + x))) + This function returns its argument. But after removing percents it + does not work: "Result of (1- n) is not a function". + +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.) + +132: + Trying to compile + (DEFUN FOO () (CATCH 0 (PRINT 1331))) + gives an error + # is not valid as the second argument to VOP: + SB-C:MAKE-CATCH-BLOCK, + since the TN's primitive type SB-VM::POSITIVE-FIXNUM doesn't allow + any of the SCs allowed by the operand restriction: + (SB-VM::DESCRIPTOR-REG) + The (CATCH 0 ...) construct is bad style (because of unportability + of EQ testing of numbers) but it is legal, and shouldn't cause an + internal compiler error. (This error occurs in sbcl-0.6.13 and in + 0.pre7.86.flaky7.14.) + +133: + Trying to compile something like + (sb!alien:def-alien-routine "breakpoint_remove" sb!c-call:void + (code-obj sb!c-call:unsigned-long) + (pc-offset sb!c-call:int) + (old-inst sb!c-call:unsigned-long)) + in SBCL-0.pre7.86.flaky7.22 after warm init fails with an error + cannot use values types here + probably because the SB-C-CALL:VOID type gets translated to (VALUES). + It should be valid to use VOID for a function return type, so perhaps + instead of calling SPECIFIER-TYPE (which excludes all VALUES types + automatically) we should call VALUES-SPECIFIER-TYPE and handle VALUES + types manually, allowing the special case (VALUES) but still excluding + all more-complex VALUES types. + +134: + (reported by Alexey Dejneka sbcl-devel 2001-12-07) + (let ((s '((1 2 3)))) + (eval (eval ``(vector ,@',@s)))) + + should return #(1 2 3), instead of this it causes a reader error. + + Interior call of BACKQUOTIFY erroneously optimizes ,@': it immediately + splices the temporal representation of ,@S. + +135: + Ideally, uninterning a symbol would allow it, and its associated + 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. + +137: + (SB-DEBUG:BACKTRACE) output should start with something + including the name BACKTRACE, not (as in 0.pre7.88) + just "0: (\"hairy arg processor\" ...)". In general + the names in BACKTRACE are all screwed up compared to + the nice useful names in 0.6.13. + + Note for those who observe that this is an annoying + bug and doesn't belong in a release: See the "note for the + ambitious", below. + + Note for the ambitious: This is an important bug and I'd + really like to fix it and spent many hours on it. The + obvious ways to fix it are hard, because the underlying + infrastructure seems to be rather broken. + * There are two mostly-separate systems for storing names, + the in-the-function-object system used by e.g. + CL:FUNCTION-LAMBDA-EXPRESSION and the + in-the-DEBUG-FUN-object system used by e.g. BACKTRACE. + The code as of sbcl-0.pre7.94 is smart enough to set + up the first value, but not the second (because I naively + assumed that one mechanism is enough, and didn't proof + read the entire system to see whether there might be + another mechanism?! argh...) + * The systems are not quite separate, but instead weirdly and + fragilely coupled by the FUN-DEBUG-FUN algorithm. + * If you try to refactor this dain bramage away, reducing + things to a single system -- I tried to add a + %SIMPLE-FUN-DEBUG-FUN slot, planning eventually to get + rid of the old %SIMPLE-FUN-NAME slot in favor of indirection + through the new slot -- you get torpedoed by the fragility + of the SIMPLE-FUN primitive object. Just adding the + new slot, without making any other changes in the system, + is enough to make the system fail with what look like + memory corruption problems in warm init. + But please do fix some or all of the problem, I'm tired + of messing with it. -- WHN 2001-12-22 + KNOWN BUGS RELATED TO THE IR1 INTERPRETER -(Note: At some point, the pure interpreter (actually a semi-pure -interpreter aka "the IR1 interpreter") will probably go away, replaced -by constructs like - (DEFUN EVAL (X) (FUNCALL (COMPILE NIL (LAMBDA ..))))) -and at that time these bugs should either go away automatically or -become more tractable to fix. Until then, they'll probably remain, -since some of them aren't considered urgent, and the rest are too hard -to fix as long as so many special cases remain. After the IR1 -interpreter goes away is also the preferred time to start -systematically exterminating cases where debugging functionality -(backtrace, breakpoint, etc.) breaks down, since getting rid of the -IR1 interpreter will reduce the number of special cases we need to -support.) - -IR1-1: - The FUNCTION special operator doesn't check properly whether its - argument is a function name. E.g. (FUNCTION (X Y)) returns a value - instead of failing with an error. (Later attempting to funcall the - value does cause an error.) - -IR1-2: - COMPILED-FUNCTION-P bogusly reports T for interpreted functions: - * (DEFUN FOO (X) (- 12 X)) - FOO - * (COMPILED-FUNCTION-P #'FOO) - T - -IR1-3: - Executing - (DEFVAR *SUPPRESS-P* T) - (EVAL '(UNLESS *SUPPRESS-P* - (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE) - (FORMAT T "surprise!")))) - prints "surprise!". Probably the entire EVAL-WHEN mechanism ought to be - rewritten from scratch to conform to the ANSI definition, abandoning - the *ALREADY-EVALED-THIS* hack which is used in sbcl-0.6.8.9 (and - in the original CMU CL source, too). This should be easier to do -- - though still nontrivial -- once the various IR1 interpreter special - cases are gone. - -IR1-3a: - EVAL-WHEN's idea of what's a toplevel form is even more screwed up - than the example in IR1-3 would suggest, since COMPILE-FILE and - COMPILE both print both "right now!" messages when compiling the - following code, - (LAMBDA (X) - (COND (X - (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE) - (PRINT "yes! right now!")) - "yes!") - (T - (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE) - (PRINT "no! right now!")) - "no!"))) - and while EVAL doesn't print the "right now!" messages, the first - FUNCALL on the value returned by EVAL causes both of them to be printed. +(Now that the IR1 interpreter has gone away, these should be +relatively straightforward to fix.) IR1-4: The system accepts DECLAIM in most places where DECLARE would be