X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=534c9998450cf8070b98d36811293001b2021e18;hb=eafc55e040c41a5fc4215d364f2b2b3bbf545810;hp=2f5f538d20cda7fba9265c26efed77dee6cb5422;hpb=aa61c7571b33b86981301f34d3acdb66666f53a3;p=sbcl.git diff --git a/BUGS b/BUGS index 2f5f538..534c999 100644 --- a/BUGS +++ b/BUGS @@ -343,11 +343,6 @@ WORKAROUND: 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. - d: ELT signals SIMPLE-ERROR if its index argument - isn't a valid index for its sequence argument, but should - signal TYPE-ERROR instead. - e: FILE-LENGTH is supposed to signal a type error when its - argument is not a stream associated with a file, but doesn't. f: (FLOAT-RADIX 2/3) should signal an error instead of returning 2. g: (LOAD "*.lsp") should signal FILE-ERROR. @@ -389,10 +384,6 @@ WORKAROUND: 50: type system errors reported by Peter Van Eynde July 25, 2000: - a: (SUBTYPEP 'BIGNUM 'INTEGER) => NIL, NIL - but should be (VALUES T T) instead. - b: (SUBTYPEP 'EXTENDED-CHAR 'CHARACTER) => NIL, NIL - but should be (VALUES T T) instead. c: (SUBTYPEP '(INTEGER (0) (0)) 'NIL) dies with nested errors. d: In general, the system doesn't like '(INTEGER (0) (0)) -- it blows up at the level of SPECIFIER-TYPE with @@ -402,8 +393,6 @@ WORKAROUND: "Component type for Complex is not numeric: (EQL 0)." This might be easy to fix; the type system already knows that (SUBTYPEP '(EQL 0) 'NUMBER) is true. - f: The type system doesn't know about the condition system, - so that e.g. (TYPEP 'SIMPLE-ERROR 'ERROR)=>NIL. g: The type system isn't all that smart about relationships between hairy types, as shown in the type.erg test results, e.g. (SUBTYPEP 'CONS '(NOT ATOM)) => NIL, NIL. @@ -430,14 +419,6 @@ WORKAROUND: need to document exactly what metaobject protocol specification we're following -- the current code is just inherited from PCL.) -53: - another error from Peter Van Eynde 5 September 2000: - (FORMAT NIL "~F" "FOO") should work, but instead reports an error. - PVE submitted a patch to deal with this bug, but it exposes other - comparably serious bugs, so I didn't apply it. It looks as though - the FORMAT code needs a fair amount of rewriting in order to comply - with the various details of the ANSI spec. - 54: The implementation of #'+ returns its single argument without type checking, e.g. (+ "illegal") => "illegal". @@ -653,21 +634,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: 72: (DECLAIM (OPTIMIZE ..)) doesn't work properly inside LOCALLY forms. -74: - As noted in the ANSI specification for COERCE, (COERCE 3 'COMPLEX) - gives a result which isn't COMPLEX. The result type optimizer - for COERCE doesn't know this, perhaps because it was written before - ANSI threw this curveball: the optimizer thinks that COERCE always - returns a result of the specified type. Thus while the interpreted - function - (DEFUN TRICKY (X) (TYPEP (COERCE X 'COMPLEX) 'COMPLEX)) - returns the correct result, - (TRICKY 3) => NIL - the compiled function - (COMPILE 'TRICKY) - does not: - (TRICKY 3) => T - 75: As reported by Martin Atzmueller on sbcl-devel 26 Dec 2000, ANSI says that WITH-OUTPUT-TO-STRING should have a keyword @@ -694,9 +660,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: LOAD-FOREIGN, and (2) hunt for any other code which uses temporary files and make it share the same new safe logic. -80: - (fixed early Feb 2001 by MNA) - 82: Functions are assigned names based on the context in which they're defined. This is less than ideal for the functions which are @@ -866,16 +829,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: the first time around, until regression tests are written I'm not comfortable merging the patches in the CVS version of SBCL. -101: - The error message for calls to structure accessors with the - wrong number of arguments is confusing and of the wrong - condition class (TYPE-ERROR instead of PROGRAM-ERROR): - * (defstruct foo x y) - * (foo-x) - debugger invoked on condition of type SIMPLE-TYPE-ERROR: - Structure for accessor FOO-X is not a FOO: - 301988783 - 102: As reported by Arthur Lemmens sbcl-devel 2001-05-05, ANSI requires that SYMBOL-MACROLET refuse to rebind special variables, @@ -885,13 +838,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: As of sbcl-0.6.12.x, this dependence on the nonconforming behavior has been fixed, but the nonconforming behavior remains.) -103: - As reported by Arthur Lemmens sbcl-devel 2001-05-05, ANSI's - definition of (LOOP .. DO ..) requires that the terms following - DO all be compound forms. SBCL's implementation of LOOP allows - non-compound forms (like the bare symbol COUNT, in his example) - here. - 104: (DESCRIBE 'SB-ALIEN:DEF-ALIEN-TYPE) reports the macro argument list incorrectly: @@ -909,12 +855,8 @@ Error in function C::GET-LAMBDA-TO-COMPILE: 106: (reported by Eric Marsden on cmucl-imp 2001-06-15) - Executing - (TYPEP 0 '(COMPLEX (EQL 0))) - signals an error in sbcl-0.6.12.34, - The component type for COMPLEX is not numeric: (EQL 0) - This is funny since sbcl-0.6.12.34 knows - (SUBTYPEP '(EQL 0) 'NUMBER) => T + (and APD pointed out on sbcl-devel 2001-12-29 that it's the same + as bug 50e) 108: (TIME (ROOM T)) reports more than 200 Mbytes consed even for @@ -1315,6 +1257,74 @@ Error in function C::GET-LAMBDA-TO-COMPILE: 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 (Now that the IR1 interpreter has gone away, these should be