0.8.1.51:

        * Update BUGS.

diff --git a/BUGS b/BUGS
index 959f0aa..19ac95c 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -276,34 +276,6 @@ WORKAROUND:
   holding... * is not equivalent to T in many cases, such as 
     (VECTOR *) /= (VECTOR T).
 
-94a: 
-  Inconsistencies between derived and declared VALUES return types for
-  DEFUN aren't checked very well. E.g. the logic which successfully
-  catches problems like
-    (declaim (ftype (function (fixnum) float) foo))
-    (defun foo (x)
-      (declare (type integer x))
-      (values x)) ; wrong return type, detected, gives warning, good!
-  fails to catch
-    (declaim (ftype (function (t) (values t t)) bar))
-    (defun bar (x)
-      (values x)) ; wrong number of return values, no warning, bad!
-  The cause of this is seems to be that (1) the internal function 
-  VALUES-TYPES-EQUAL-OR-INTERSECT used to make the check handles its
-  arguments symmetrically, and (2) when the type checking code was
-  written back when when SBCL's code was still CMU CL, the intent
-  was that this case
-    (declaim (ftype (function (t) t) bar))
-    (defun bar (x)
-      (values x x)) ; wrong number of return values; should give warning?
-  not be warned for, because a two-valued return value is considered
-  to be compatible with callers who expects a single value to be
-  returned. That intent is probably not appropriate for modern ANSI
-  Common Lisp, but fixing this might be complicated because of other
-  divergences between auld-style and new-style handling of
-  multiple-VALUES types. (Some issues related to this were discussed
-  on cmucl-imp at some length sometime in 2000.)
-
 95:
   The facility for dumping a running Lisp image to disk gets confused
   when run without the PURIFY option, and creates an unnecessarily large
@@ -846,22 +818,7 @@ WORKAROUND:
    Then (FOO #\1 *STANDARD-OUTPUT*) signals type error.
 
   (In 0.7.9.1 the result type is (FUNCTION * *), so Python does not
-  produce invalid code, but type checking is not accurate. Similar
-  problems exist with VALUES-TYPE-INTERSECTION.)
-
-220:
-  Sbcl 0.7.9 fails to compile
-
-  (multiple-value-call #'list
-    (the integer (helper))
-    nil)
-
-  Type check for INTEGER, the result of which serves as the first
-  argument of M-V-C, is inserted after evaluation of NIL. So arguments
-  of M-V-C are pushed in the wrong order. As a temporary workaround
-  type checking was disabled for M-V-Cs in 0.7.9.13. A better solution
-  would be to put the check between evaluation of arguments, but it
-  could be tricky to check result types of PROG1, IF etc.
+  produce invalid code, but type checking is not accurate.)
 
 233: bugs in constraint propagation
   a.

diff --git a/NEWS b/NEWS
index 47b6ad0..176d786 100644 (file)
--- a/NEWS
+++ b/NEWS
@@ -1928,6 +1928,8 @@ changes in sbcl-0.8.2 relative to sbcl-0.8.1:
     STRING-INPUT-STREAMs.  (thanks to Nikodemus Siivola)
   * bug fix: (SIGNED-BYTE 8) streams no longer return (UNSIGNED-BYTE
     8) data.  (thanks to David Lichteblau)
+  * bug fix: it is possible to add a method to a generic function
+    without lambda list.
   * fixed some bugs revealed by Paul Dietz' test suite:
     ** LAST and [N]BUTLAST should accept a bignum.
     ** condition slot accessors are methods.

diff --git a/OPTIMIZATIONS b/OPTIMIZATIONS
index fd575d6..3c3edea 100644 (file)
--- a/OPTIMIZATIONS
+++ b/OPTIMIZATIONS
@@ -62,11 +62,6 @@ VOP DATA-VECTOR-SET/SIMPLE-STRING V2!14[EDI] t32[EAX] t30[S2]>t33[CL]
 
 * And why two moves?
 --------------------------------------------------------------------------------
-#5
-(loop repeat 1.5)
-
-uses generic arithmetic
---------------------------------------------------------------------------------
 #6
 09:49:05 <jtra> I have found a case in those where suboptimal code is
   generate with nested loops, it might be moderately easy to fix that

diff --git a/version.lisp-expr b/version.lisp-expr
index 616da6a..a6eec2a 100644 (file)
--- a/version.lisp-expr
+++ b/version.lisp-expr
@@ -17,4 +17,4 @@
 ;;; checkins which aren't released. (And occasionally for internal
 ;;; versions, especially for internal versions off the main CVS
 ;;; branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".)
-"0.8.1.50"
+"0.8.1.51"