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.
           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.
        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:
 
 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
        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.
           "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.
        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.)
 
   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".
 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.
 
 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
 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.
 
   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
 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.
 
   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,
 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.)
 
   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:
 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)
 
 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
 
 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.
 
   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 
 KNOWN BUGS RELATED TO THE IR1 INTERPRETER
 
 (Now that the IR1 interpreter has gone away, these should be