X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=b849dad7e12ff677fd5f22193c7d2c586c277439;hb=e8b69b1dd5564a4237b1bdc1060820c3b820cde2;hp=c7c5c47cfba02bbf96afae2fab44326181bbdcbc;hpb=17d48b6525fdd5f188961c863e1d1f1d44d29107;p=sbcl.git

diff --git a/BUGS b/BUGS
index c7c5c47..b849dad 100644
--- a/BUGS
+++ b/BUGS
@@ -1286,6 +1286,103 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   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
+    #<SB-C:TN '0!1> 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
 
 (Now that the IR1 interpreter has gone away, these should be