an error may be signalled at read time and it would be good if
SBCL did it.
- c: Reading of not initialized slot sometimes causes SEGV (for inline
- accessors it is fixed, but out-of-line still do not perform type
- check).
-
- d:
- (declaim (optimize (safety 3) (speed 1) (space 1)))
- (defstruct foo
- x y)
- (defstruct (stringwise-foo (:include foo
- (x "x" :type simple-string)
- (y "y" :type simple-string))))
- (defparameter *stringwise-foo*
- (make-stringwise-foo))
- (setf (foo-x *stringwise-foo*) 0)
- (defun frob-stringwise-foo (sf)
- (aref (stringwise-foo-x sf) 0))
- (frob-stringwise-foo *stringwise-foo*)
- SEGV.
+ d: (fixed in 0.8.1.5)
7:
The "compiling top-level form:" output ought to be condensed.
(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
so the compiler doesn't compile the type test into code, but
instead just saves the type in a lexical closure and interprets it
at runtime.
- A proper solution involves deciding whether it's really worth
- saving space by implementing structure slot accessors as closures.
- (If it's not worth it, the problem vanishes automatically. If it
- is worth it, there are hacks we could use to force type tests to
- be compiled anyway, and even shared. E.g. we could implement
- an EQUAL hash table mapping from types to compiled type tests,
- and save the appropriate compiled type test as part of each lexical
- closure; or we could make the lexical closures be placeholders
- which overwrite their old definition as a lexical closure with
- a new compiled definition the first time that they're called.)
- As a workaround for the problem, #'(SETF FOO) expressions can
- be replaced with (EFFICIENT-SETF-FUNCTION FOO), where
+ To exercise the problem, compile and load
+ (cl:in-package :cl-user)
+ (defstruct foo
+ (bar (error "missing") :type bar))
+ (defvar *foo*)
+ (defun wastrel1 (x)
+ (loop (setf (foo-bar *foo*) x)))
+ (defstruct bar)
+ (defvar *bar* (make-bar))
+ (defvar *foo* (make-foo :bar *bar*))
+ (defvar *setf-foo-bar* #'(setf foo-bar))
+ (defun wastrel2 (x)
+ (loop (funcall *setf-foo-bar* x *foo*)))
+ then run (WASTREL1 *BAR*) or (WASTREL2 *BAR*), hit Ctrl-C, and
+ use BACKTRACE, to see it's spending all essentially all its time
+ in %TYPEP and VALUES-SPECIFIER-TYPE and so forth.
+ One possible solution would be simply to give up on
+ representing structure slot accessors as functions, and represent
+ them as macroexpansions instead. This can be inconvenient for users,
+ but it's not clear that it's worse than trying to help by expanding
+ into a horribly inefficient implementation.
+ As a workaround for the problem, #'(SETF FOO) expressions
+ can be replaced with (EFFICIENT-SETF-FUNCTION FOO), where
(defmacro efficient-setf-function (place-function-name)
(or #+sbcl (and (sb-int:info :function :accessor-for place-function-name)
;; a workaround for the problem, encouraging the
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 problem 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)
+
+259:
+ (compile nil '(lambda () (aref (make-array 0) 0))) compiles without
+ warning. Analogous cases with the index and length being equal and
+ greater than 0 are warned for; the problem here seems to be that the
+ type required for an array reference of this type is (INTEGER 0 (0))
+ which is canonicalized to NIL.
+
DEFUNCT CATEGORIES OF BUGS
IR1-#:
These labels were used for bugs related to the old IR1 interpreter.
projects / sbcl.git / blobdiff