From: William Harold Newman Date: Tue, 22 Jan 2002 16:20:19 +0000 (+0000) Subject: 0.7.0.4: X-Git-Url: http://repo.macrolet.net/gitweb/?a=commitdiff_plain;h=8e1b4cac0a0f045542ac071c60c323f1fd14c328;p=sbcl.git 0.7.0.4: (first displayed and caused confusion on the sbcl-devel mailing list by misunderstanding the COMPLEX type specifier, completely overlooking UPGRADED-COMPLEX-PART-TYPE; then belatedly:) merged CSR "rough patch to fix bug 106" sbcl-devel 2001-10-28 used (SPECIFIER-TYPE NIL) instead of (SPECIFIER-TYPE 'NULL) in the bug 106 patch removed bug 93 entry, since CSR pointed out that the "removed bogus DECLAIM" in 0.pre7.14.flaky4.3 seems to've fixed it --- diff --git a/BUGS b/BUGS index ed532b3..ba07940 100644 --- a/BUGS +++ b/BUGS @@ -332,10 +332,6 @@ WORKAROUND: blows up at the level of SPECIFIER-TYPE with "Lower bound (0) is greater than upper bound (0)." Probably SPECIFIER-TYPE should return NIL instead. - e: (TYPEP 0 '(COMPLEX (EQL 0)) fails with - "Component type for Complex is not numeric: (EQL 0)." - This might be easy to fix; the type system already knows - that (SUBTYPEP '(EQL 0) 'NUMBER) is true. 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. @@ -633,8 +629,8 @@ Error in function C::GET-LAMBDA-TO-COMPILE: (assert (not (eq type1 *wild-type*))) in the NAMED :SIMPLE-= type method.) '* isn't really a type, and in a type context should probably be translated to T, and so it's - probably to ask whether it's equal to the T type and then (using the - EQ type comparison in the NAMED :SIMPLE-= type method) return NIL. + probably wrong to ask whether it's equal to the T type and then (using + the EQ type comparison in the NAMED :SIMPLE-= type method) return NIL. (I haven't tried to investigate this bug enough to guess whether there might be any user-level symptoms.) @@ -658,25 +654,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: clear what's the best fix. (See the "bug in type handling" discussion on cmucl-imp ca. 2001-03-22 and ca. 2001-02-12.) -93: - In sbcl-0.6.11.26, (COMPILE 'IN-HOST-COMPILATION-MODE) in - src/cold/shared.lisp doesn't correctly translate the - interpreted function - (defun in-host-compilation-mode (fn) - (let ((*features* (cons :sb-xc-host *features*)) - ;; the CROSS-FLOAT-INFINITY-KLUDGE, as documented in - ;; base-target-features.lisp-expr: - (*shebang-features* (set-difference *shebang-features* - '(:sb-propagate-float-type - :sb-propagate-fun-type)))) - (with-additional-nickname ("SB-XC" "SB!XC") - (funcall fn)))) - No error is reported by the compiler, but when the function is executed, - it causes an error - TYPE-ERROR in SB-KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER: - (:LINUX :X86 :IEEE-FLOATING-POINT :SB-CONSTRAIN-FLOAT-TYPE :SB-TEST - :SB-INTERPRETER :SB-DOC :UNIX ...) is not of type SYMBOL. - 94a: Inconsistencies between derived and declared VALUES return types for DEFUN aren't checked very well. E.g. the logic which successfully @@ -781,11 +758,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: /usr/stuff/sbcl/src/code/host-alieneval.lisp Created: Monday, March 12, 2001 07:47:43 AM CST -106: - (reported by Eric Marsden on cmucl-imp 2001-06-15) - (and APD pointed out on sbcl-devel 2001-12-29 that it's the same - as bug 50e) - 108: (TIME (ROOM T)) reports more than 200 Mbytes consed even for a clean, just-started SBCL system. And it seems to be right: @@ -1266,6 +1238,14 @@ Error in function C::GET-LAMBDA-TO-COMPILE: interpreter is gone, the system's notion of what's a top-level form and what's not will remain too confused to fix this problem.] +145: + ANSI allows types `(COMPLEX ,FOO) to use very hairy values for + FOO, e.g. (COMPLEX (AND REAL (SATISFIES ODDP))). The old CMU CL + COMPLEX implementation didn't deal with this, and hasn't been + upgraded to do so. (This doesn't seem to be a high priority + conformance problem, since seems hard to construct useful code + where it matters.) + DEFUNCT CATEGORIES OF BUGS IR1-#: These numbers were used for bugs related to the old IR1 diff --git a/src/code/late-type.lisp b/src/code/late-type.lisp index eec991e..96b5a81 100644 --- a/src/code/late-type.lisp +++ b/src/code/late-type.lisp @@ -1277,34 +1277,80 @@ (if (eq typespec '*) (make-numeric-type :complexp :complex) (labels ((not-numeric () - ;; FIXME: should probably be TYPE-ERROR (error "The component type for COMPLEX is not numeric: ~S" typespec)) + (not-real () + (error "The component type for COMPLEX is not real: ~S" + typespec)) (complex1 (component-type) (unless (numeric-type-p component-type) - ;; FIXME: As per the FIXME below, ANSI says we're - ;; supposed to handle any subtype of REAL, not only - ;; those which can be represented as NUMERIC-TYPE. (not-numeric)) (when (eq (numeric-type-complexp component-type) :complex) - (error "The component type for COMPLEX is complex: ~S" - typespec)) - (modified-numeric-type component-type :complexp :complex))) - (let ((type (specifier-type typespec))) - (typecase type - ;; This is all that CMU CL handled. - (numeric-type (complex1 type)) - ;; We need to handle UNION-TYPEs in order to deal with - ;; REAL and FLOAT being represented as UNION-TYPEs of more - ;; primitive types. + (not-real)) + (modified-numeric-type component-type :complexp :complex)) + (complex-union (component) + (unless (numberp component) + (not-numeric)) + ;; KLUDGE: This TYPECASE more or less does + ;; (UPGRADED-COMPLEX-PART-TYPE (TYPE-OF COMPONENT)), + ;; (plus a small hack to treat (EQL COMPONENT 0) specially) + ;; but uses logic cut and pasted from the DEFUN of + ;; UPGRADED-COMPLEX-PART-TYPE. That's fragile, because + ;; changing the definition of UPGRADED-COMPLEX-PART-TYPE + ;; would tend to break the code here. Unfortunately, + ;; though, reusing UPGRADED-COMPLEX-PART-TYPE here + ;; would cause another kind of fragility, because + ;; ANSI's definition of TYPE-OF is so weak that e.g. + ;; (UPGRADED-COMPLEX-PART-TYPE (TYPE-OF 1/2)) could + ;; end up being (UPGRADED-COMPLEX-PART-TYPE 'REAL) + ;; instead of (UPGRADED-COMPLEX-PART-TYPE 'RATIONAL). + ;; So using TYPE-OF would mean that ANSI-conforming + ;; maintenance changes in TYPE-OF could break the code here. + ;; It's not clear how best to fix this. -- WHN 2002-01-21, + ;; trying to summarize CSR's concerns in his patch + (typecase component + (complex (error "The component type for COMPLEX (EQL X) ~ + is complex: ~S" + component)) + ((eql 0) (specifier-type nil)) ; as required by ANSI + (single-float (specifier-type '(complex single-float))) + (double-float (specifier-type '(complex double-float))) + #!+long-float + (long-float (specifier-type '(complex long-float))) + (rational (specifier-type '(complex rational))) + (t (specifier-type '(complex real)))))) + (let ((ctype (specifier-type typespec))) + (typecase ctype + (numeric-type (complex1 ctype)) (union-type (apply #'type-union + ;; FIXME: This code could suffer from + ;; (admittedly very obscure) cases of + ;; bug 145 e.g. when TYPE is + ;; (OR (AND INTEGER (SATISFIES ODDP)) + ;; (AND FLOAT (SATISFIES FOO)) + ;; and not even report the problem very well. (mapcar #'complex1 - (union-type-types type)))) - ;; FIXME: ANSI just says that TYPESPEC is a subtype of type - ;; REAL, not necessarily a NUMERIC-TYPE. E.g. TYPESPEC could - ;; legally be (AND REAL (SATISFIES ODDP))! But like the old - ;; CMU CL code, we're still not nearly that general. - (t (not-numeric))))))) + (union-type-types ctype)))) + ;; MEMBER-TYPE is almost the same as UNION-TYPE, but + ;; there's a gotcha: (COMPLEX (EQL 0)) is, according to + ;; ANSI, equal to type NIL, the empty set. + (member-type (apply #'type-union + (mapcar #'complex-union + (member-type-members ctype)))) + (t + (multiple-value-bind (subtypep certainly) + (csubtypep ctype (specifier-type 'real)) + (if (and (not subtypep) certainly) + (not-real) + ;; ANSI just says that TYPESPEC is any subtype of + ;; type REAL, not necessarily a NUMERIC-TYPE. In + ;; particular, at this point TYPESPEC could legally be + ;; an intersection type like (AND REAL (SATISFIES ODDP)), + ;; in which case we fall through the logic above and + ;; end up here, stumped. + (error "~@" typespec))))))))) ;;; If X is *, return NIL, otherwise return the bound, which must be a ;;; member of TYPE or a one-element list of a member of TYPE. diff --git a/version.lisp-expr b/version.lisp-expr index 3218fda..282b24e 100644 --- a/version.lisp-expr +++ b/version.lisp-expr @@ -18,4 +18,4 @@ ;;; for internal versions, especially for internal versions off the ;;; main CVS branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".) -"0.7.0.3" +"0.7.0.4"