X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=b849dad7e12ff677fd5f22193c7d2c586c277439;hb=683874b497a99cd2c11b6c5d9b47e2785b1ede5f;hp=2c29d33917ab91bbffd8727c4fc806d4820efd03;hpb=9514c25e89aad10784c6d04fea4595d8c8ae68cc;p=sbcl.git diff --git a/BUGS b/BUGS index 2c29d33..b849dad 100644 --- a/BUGS +++ b/BUGS @@ -1193,6 +1193,195 @@ Error in function C::GET-LAMBDA-TO-COMPILE: 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