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
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.
Urgh... It's time to write IR1-copier.
-262:
- In 0.8.1.32:
-
- * (ensure-generic-function 'foo)
- #<STANDARD-GENERIC-FUNCTION FOO (0)>
- * (defmethod foo (x) x)
- debugger invoked on condition of type SIMPLE-ERROR:
- The generic function #<STANDARD-GENERIC-FUNCTION FOO (0)> takes 0 required
- arguments; was asked to find a method with specializers (#<BUILT-IN-CLASS T>)
-
- AMOP seems to say that it should work (first ADD-METHOD initializes
- GF lambda list).
-
-264:
- (reported by <dsk> on #lisp 2003-07-16)
-
- (progv '(foo) '(1)
- (eval '(symbol-macrolet ((foo 3))
- (declare (special foo))
- foo)))
-
- does not signal an error.
-
- (fixed in 0.8.1.37)
-
265:
SB-EXT:RUN-PROGRAM is currently non-functional on Linux/PPC;
attempting to use it leads to segmentation violations. This is
is allowed to by CLHS 3.2.2.3. CMUCL, however, does perform this
optimization.
+268: "wrong free declaration scope"
+ The following code must signal type error:
+
+ (locally (declare (optimize (safety 3)))
+ (flet ((foo (x &optional (y (car x)))
+ (declare (optimize (safety 0)))
+ (list x y)))
+ (funcall (eval #'foo) 1)))
+
+269:
+ SCALE-FLOAT should accept any integer for its second argument.
+
DEFUNCT CATEGORIES OF BUGS
IR1-#:
These labels were used for bugs related to the old IR1 interpreter.