blows up at the level of SPECIFIER-TYPE with
"Lower bound (0) is greater than upper bound (0)." Probably
SPECIFIER-TYPE should return the NIL type instead.
- 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 [still] isn't all that smart about relationships
+ between hairy types. [The original example from PVE was
+ (SUBTYPEP 'CONS '(NOT ATOM)) => NIL, NIL, which was fixed
+ by CSR in sbcl-0.7.1.28, but there are still
+ plenty of corner cases out there.]
51:
miscellaneous errors reported by Peter Van Eynde July 25, 2000:
T
T
+ This is probably due to underzealous clearing of the type caches; a
+ brute-force solution in that case would be to make a defclass expand
+ into something that included a call to SB-KERNEL::CLEAR-TYPE-CACHES,
+ but there may be a better solution.
+
141:
Pretty-printing nested backquotes doesn't work right, as
reported by Alexey Dejneka sbcl-devel 2002-01-13:
them as TYPE-ERRORs (reporting the problem as something not being
coerceable to a function).
+153:
+ (essentially the same problem as a CMU CL bug reported by Martin
+ Cracauer on cmucl-imp 2002-02-19)
+ There is a hole in structure slot type checking. Compiling and LOADing
+ (declaim (optimize safety))
+ (defstruct foo
+ (bla 0 :type fixnum))
+ (defun f ()
+ (let ((foo (make-foo)))
+ (setf (foo-bla foo) '(1 . 1))
+ (format t "Is ~a of type ~a a cons? => ~a~%"
+ (foo-bla foo)
+ (type-of (foo-bla foo))
+ (consp (foo-bla foo)))))
+ (f)
+ should signal an error, but in sbcl-0.7.1.21 instead gives the output
+ Is (1 . 1) of type CONS a cons? => NIL
+ without signalling an error.
+
DEFUNCT CATEGORIES OF BUGS
IR1-#:
These labels were used for bugs related to the old IR1 interpreter.
- The # values reached 6 before the category was closed down.
\ No newline at end of file
+ The # values reached 6 before the category was closed down.