X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=fb3f80d332a8bbf779665177ec984b21dcedb9aa;hb=0da101cd78f9b7b772f6a469ade38b01e5de982b;hp=0e990ce6ff103296b8ce3973603a56ef6f94ed33;hpb=832f3b5652ae1b4a8888829cd4a1b391a8ca9952;p=sbcl.git diff --git a/BUGS b/BUGS index 0e990ce..fb3f80d 100644 --- a/BUGS +++ b/BUGS @@ -635,31 +635,6 @@ WORKAROUND: This is probably the same bug as 162 -217: "Bad type operations with FUNCTION types" - In sbcl.0.7.7: - - * (values-type-union (specifier-type '(function (base-char))) - (specifier-type '(function (integer)))) - - # - - It causes insertion of wrong type assertions into generated - code. E.g. - - (defun foo (x s) - (let ((f (etypecase x - (character #'write-char) - (integer #'write-byte)))) - (funcall f x s) - (etypecase x - (character (write-char x s)) - (integer (write-byte x s))))) - - 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.) - 235: "type system and inline expansion" a. (declaim (ftype (function (cons) number) acc)) @@ -675,6 +650,10 @@ WORKAROUND: (foo '(nil) '(t)) => NIL, T. + As of 0.9.15.41 this seems to be due to ACC being inlined only once + inside FOO, which results in the second call reusing the FUNCTIONAL + resulting from the first -- which doesn't check the type. + 237: "Environment arguments to type functions" a. Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and UPGRADED-COMPLEX-PART-TYPE now have an optional environment @@ -1009,13 +988,8 @@ WORKAROUND: The problem is that both EVALs sequentially write to the same LVAR. 306: "Imprecise unions of array types" - a.(defun foo (x) - (declare (optimize speed) - (type (or (array cons) (array vector)) x)) - (elt (aref x 0) 0)) - (foo #((0))) => TYPE-ERROR - relatedly, + a. fixed in SBCL 0.9.15.48 b.(subtypep 'array @@ -1430,80 +1404,6 @@ WORKAROUND: Expected: ERROR Got: # -367: TYPE-ERROR at compile time, undetected TYPE-ERROR at runtime - This test program - (declaim (optimize (safety 3) (debug 2) (speed 2) (space 1))) - (defstruct e367) - (defstruct i367) - (defstruct g367 - (i367s (make-array 0 :fill-pointer t) :type (or (vector i367) null))) - (defstruct s367 - (g367 (error "missing :G367") :type g367 :read-only t)) - ;;; In sbcl-0.8.18, commenting out this (DECLAIM (FTYPE ... R367)) - ;;; gives an internal error at compile time: - ;;; The value # is not of - ;;; type SB-KERNEL:VALUES-TYPE. - (declaim (ftype (function ((vector i367) e367) (or s367 null)) r367)) - (declaim (ftype (function ((vector e367)) (values)) h367)) - (defun frob (v w) - (let ((x (g367-i367s (make-g367)))) - (let* ((y (or (r367 x w) - (h367 x))) - (z (s367-g367 y))) - (format t "~&Y=~S Z=~S~%" y z) - (g367-i367s z)))) - (defun r367 (x y) (declare (ignore x y)) nil) - (defun h367 (x) (declare (ignore x)) (values)) - ;;; In sbcl-0.8.18, executing this form causes an low-level error - ;;; segmentation violation at #X9B0E1F4 - ;;; (instead of the TYPE-ERROR that one might like). - (frob 0 (make-e367)) - can be made to cause two different problems, as noted in the comments: - bug 367a: Compile and load the file. No TYPE-ERROR is signalled at - run time (in the (S367-G367 Y) form of FROB, when Y is NIL - instead of an instance of S367). Instead (on x86/Linux at least) - we end up with a segfault. - bug 367b: Comment out the (DECLAIM (FTYPE ... R367)), and compile - the file. The compiler fails with TYPE-ERROR at compile time. - -368: miscompiled OR (perhaps related to bug 367) - Trying to relax type declarations to find a workaround for bug 367, - it turns out that even when the return type isn't declared (or - declared to be T, anyway) the system remains confused about type - inference in code similar to that for bug 367: - (in-package :cl-user) - (declaim (optimize (safety 3) (debug 2) (speed 2) (space 1))) - (defstruct e368) - (defstruct i368) - (defstruct g368 - (i368s (make-array 0 :fill-pointer t) :type (or (vector i368) null))) - (defstruct s368 - (g368 (error "missing :G368") :type g368 :read-only t)) - (declaim (ftype (function (fixnum (vector i368) e368) t) r368)) - (declaim (ftype (function (fixnum (vector e368)) t) h368)) - (defparameter *h368-was-called-p* nil) - (defun nsu (vertices e368) - (let ((i368s (g368-i368s (make-g368)))) - (let ((fuis (r368 0 i368s e368))) - (format t "~&FUIS=~S~%" fuis) - (or fuis (h368 0 i368s))))) - (defun r368 (w x y) - (declare (ignore w x y)) - nil) - (defun h368 (w x) - (declare (ignore w x)) - (setf *h368-was-called-p* t) - (make-s368 :g368 (make-g368))) - (trace r368 h368) - (format t "~&calling NSU~%") - (let ((nsu (nsu #() (make-e368)))) - (format t "~&NSU returned ~S~%" nsu) - (format t "~&*H368-WAS-CALLED-P*=~S~%" *h368-was-called-p*) - (assert (s368-p nsu)) - (assert *h368-was-called-p*)) - In sbcl-0.8.18, both ASSERTs fail, and (DISASSEMBLE 'NSU) shows - that no call to H368 is compiled. - 369: unlike-an-intersection behavior of VALUES-TYPE-INTERSECTION In sbcl-0.8.18.2, the identity $(x \cap y \cap y)=(x \cap y)$ does not hold for VALUES-TYPE-INTERSECTION, even for types which @@ -1641,16 +1541,6 @@ WORKAROUND: stack exhaustion checking (implemented with a write-protected guard page) does not work on SunOS/x86. -387: - 12:10 < jsnell> the package-lock test is basically due to a change in the test - behaviour when you install a handler for error around it. I - thought I'd disabled the test for now, but apparently that was - my imagination - 12:19 < Xophe> jsnell: ah, I see the problem in the package-locks stuff - 12:19 < Xophe> it's the same problem as we had with compiler-error conditions - 12:19 < Xophe> the thing that's signalled up and down the stack is a subtype of - ERROR, where it probably shouldn't be - 388: (found by Dmitry Bogomolov) @@ -1812,3 +1702,53 @@ WORKAROUND: VECTOR-POP: #() has length zero perhaps because CLISP has shuffled the clauses into an ANSI-compliant order before proceeding. + +405: a TYPE-ERROR in MERGE-LETS exercised at DEBUG 3 + In sbcl-0.9.16.21 on linux/86, compiling + (declaim (optimize (debug 3))) + (defstruct foo bar) + (let () + (flet ((i (x) (frob x (foo-bar foo)))) + (i :five))) + causes a TYPE-ERROR + The value NIL is not of type SB-C::PHYSENV. + in MERGE-LETS. + +406: functional has external references -- failed aver + Given the following food in a single file + (eval-when (:compile-toplevel :load-toplevel :execute) + (defstruct foo3)) + (defstruct bar + (foo #.(make-foo3))) + as of 0.9.18.11 the file compiler breaks on it: + failed AVER: "(NOT (FUNCTIONAL-HAS-EXTERNAL-REFERENCES-P CLAMBDA))" + Defining the missing MAKE-LOAD-FORM method makes the error go away. + +407: misoptimization of loop, COERCE 'FLOAT, and HANDLER-CASE for bignums + (reported by Ariel Badichi on sbcl-devel 2007-01-09) + 407a: In sbcl-1.0.1 on Linux x86, + (defun foo () + (loop for n from (expt 2 1024) do + (handler-case + (coerce n 'single-float) + (simple-type-error () + (format t "Got here.~%") + (return-from foo))))) + (foo) + causes an infinite loop, where handling the error would be expected. + 407b: In sbcl-1.0.1 on Linux x86, + (defun bar () + (loop for n from (expt 2 1024) do + (handler-case + (format t "~E~%" (coerce n 'single-float)) + (simple-type-error () + (format t "Got here.~%") + (return-from bar))))) + fails to compile, with + Too large to be represented as a SINGLE-FLOAT: ... + from + 0: ((LABELS SB-BIGNUM::CHECK-EXPONENT) ...) + 1: ((LABELS SB-BIGNUM::FLOAT-FROM-BITS) ...) + 2: (SB-KERNEL:%SINGLE-FLOAT ...) + 3: (SB-C::BOUND-FUNC ...) + 4: (SB-C::%SINGLE-FLOAT-DERIVE-TYPE-AUX ...)