0.pre7.105:
[sbcl.git] / BUGS
diff --git a/BUGS b/BUGS
index 2f5f538..534c999 100644 (file)
--- 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