(during macroexpansion of IN-PACKAGE,
during macroexpansion of DEFFOO)
-15:
- (SUBTYPEP '(FUNCTION (T BOOLEAN) NIL)
- '(FUNCTION (FIXNUM FIXNUM) NIL)) => T, T
- (Also, when this is fixed, we can enable the code in PROCLAIM which
- checks for incompatible FTYPE redeclarations.)
-
19:
(I *think* this is a bug. It certainly seems like strange behavior. But
the ANSI spec is scary, dark, and deep.. -- WHN)
46:
type safety errors reported by Peter Van Eynde July 25, 2000:
- c: (COERCE 'AND 'FUNCTION) returns something related to
- (MACRO-FUNCTION 'AND), but ANSI says it should raise an error.
k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is
not a binary input stream, but instead cheerfully reads from
character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc").
60:
The debugger LIST-LOCATIONS command doesn't work properly.
+ (How should it work properly?)
61:
Compiling and loading
See also bugs #45.c and #183
-148:
- In sbcl-0.7.1.3 on x86, COMPILE-FILE on the file
- (in-package :cl-user)
- (defvar *thing*)
- (defvar *zoom*)
- (defstruct foo bar bletch)
- (defun %zeep ()
- (labels ((kidify1 (kid)
- )
- (kid-frob (kid)
- (if *thing*
- (setf sweptm
- (m+ (frobnicate kid)
- sweptm))
- (kidify1 kid))))
- (declare (inline kid-frob))
- (map nil
- #'kid-frob
- (the simple-vector (foo-bar perd)))))
- fails with
- debugger invoked on condition of type TYPE-ERROR:
- The value NIL is not of type SB-C::NODE.
- The location of this failure has moved around as various related
- issues were cleaned up. As of sbcl-0.7.1.9, it occurs in
- NODE-BLOCK called by LAMBDA-COMPONENT called by IR2-CONVERT-CLOSURE.
-
- (Python LET-converts KIDIFY1 into KID-FROB, then tries to inline
- expand KID-FROB into %ZEEP. Having partially done it, it sees a call
- of KIDIFY1, which already does not exist. So it gives up on
- expansion, leaving garbage consisting of infinished blocks of the
- partially converted function.)
-
- (due to reordering of the compiler this example is compiled
- successfully by 0.7.14, but the bug probably remains)
-
162:
(reported by Robert E. Brown 2002-04-16)
When a function is called with too few arguments, causing the
(print (incf start 22))
(print (incf start 26))))))
+ This example could be solved with clever enough constraint
+ propagation or with SSA, but consider
+
+ (let ((x 0))
+ (loop (incf x 2)))
+
+ The careful type of X is {2k} :-(. Is it really important to be
+ able to work with unions of many intervals?
+
190: "PPC/Linux pipe? buffer? bug"
In sbcl-0.7.6, the run-program.test.sh test script sometimes hangs
on the PPC/Linux platform, waiting for a zombie env process. This
c. the examples in CLHS 7.6.5.1 (regarding generic function lambda
lists and &KEY arguments) do not signal errors when they should.
-
201: "Incautious type inference from compound types"
a. (reported by APD sbcl-devel 2002-09-17)
(DEFUN FOO (X)
257:
Complex array type does not have corresponding type specifier.
+ This is a problem because the compiler emits optimization notes when
+ you use a non-simple array, and without a type specifier for hairy
+ array types, there's no good way to tell it you're doing it
+ intentionally so that it should shut up and just compile the code.
+
+ Another poblem is confusing error message "asserted type ARRAY
+ conflicts with derived type (VALUES SIMPLE-VECTOR &OPTIONAL)" during
+ compiling (LAMBDA (V) (VALUES (SVREF V 0) (VECTOR-POP V))).
+
+ The last problem is that when type assertions are converted to type
+ checks, types are represented with type specifiers, so we could lose
+ complex attribute. (Now this is probably not important, because
+ currently checks for complex arrays seem to be performed by
+ callees.)
+
+258:
+ (fixed in 0.8.1.3)
+
DEFUNCT CATEGORIES OF BUGS
IR1-#:
These labels were used for bugs related to the old IR1 interpreter.