X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=87c19e66bed85ec1db1545d15cd24dafd6ca8d56;hb=e4542bc034db18cf98f005b2dac53a6d7d5c7260;hp=071dde6ee79c048b75324787a835d3d2bff31970;hpb=175c318c892b0627b36fa3c4db66f59680242204;p=sbcl.git

diff --git a/BUGS b/BUGS
index 071dde6..87c19e6 100644
--- a/BUGS
+++ b/BUGS
@@ -94,6 +94,9 @@ WORKAROUND:
   And as long as we're wishing, it would be awfully nice if INSPECT could
   also report on closures, telling about the values of the bound variables.
 
+  Currently INSPECT and DESCRIBE do show the values, but showing the
+  names of the bindings would be even nicer.
+
 35:
   The compiler assumes that any time a function of declared FTYPE
   doesn't signal an error, its arguments were of the declared type.
@@ -2097,3 +2100,37 @@ WORKAROUND:
   According to <http://alfa.s145.xrea.com/sbcl/solaris-x86.html>, the
   stack exhaustion checking (implemented with a write-protected guard
   page) does not work on SunOS/x86.
+
+387:
+  12:10 < jsnell> the package-lock test is basically due to a change in the test 
+                  behaviour when you install a handler for error around it. I 
+                  thought I'd disabled the test for now, but apparently that was 
+                  my imagination
+  12:19 < Xophe> jsnell: ah, I see the problem in the package-locks stuff
+  12:19 < Xophe> it's the same problem as we had with compiler-error conditions
+  12:19 < Xophe> the thing that's signalled up and down the stack is a subtype of
+                  ERROR, where it probably shouldn't be
+
+388:
+  (found by Dmitry Bogomolov)
+
+    (defclass foo () ((x :type (unsigned-byte 8))))
+    (defclass bar () ((x :type symbol)))
+    (defclass baz (foo bar) ())
+
+  causes error
+
+    SB-PCL::SPECIALIZER-APPLICABLE-USING-TYPE-P cannot handle the second argument
+    (UNSIGNED-BYTE 8).
+
+389:
+  (reported several times on sbcl-devel, by Rick Taube, Brian Rowe and
+  others)
+
+  ROUND-NUMERIC-BOUND assumes that float types always have a FORMAT
+  specifying whether they're SINGLE or DOUBLE.  This is true for types
+  computed by the type system itself, but the compiler type derivation
+  short-circuits this and constructs non-canonical types.  A temporary
+  fix was made to ROUND-NUMERIC-BOUND for the sbcl-0.9.6 release, but
+  the right fix is to remove the abstraction violation in the
+  compiler's type deriver.