#+NIL) and I'd like to go back to see whether this really is
a compiler bug before I delete this BUGS entry.
+123:
+ The *USE-IMPLEMENTATION-TYPES* hack causes bugs, particularly
+ (IN-PACKAGE :SB-KERNEL)
+ (TYPE= (SPECIFIER-TYPE '(VECTOR T))
+ (SPECIFIER-TYPE '(VECTOR UNDEFTYPE)))
+ Then because of this, the compiler bogusly optimizes
+ (TYPEP #(11) '(SIMPLE-ARRAY UNDEF-TYPE 1))
+ to T. Unfortunately, just setting *USE-IMPLEMENTATION-TYPES* to
+ NIL around sbcl-0.pre7.14.flaky4.12 didn't work: the compiler complained
+ about type mismatches (probably harmlessly, another instance of bug 117);
+ and then cold init died with a segmentation fault.
+
+124:
+ As of version 0.pre7.14, SBCL's implementation of MACROLET makes
+ the entire lexical environment at the point of MACROLET available
+ in the bodies of the macroexpander functions. In particular, it
+ allows the function bodies (which run at compile time) to try to
+ access lexical variables (which are only defined at runtime).
+ It doesn't even issue a warning, which is bad.
+
+ The SBCL behavior arguably conforms to the ANSI spec (since the
+ spec says that the behavior is undefined, ergo anything conforms).
+ However, it would be better to issue a compile-time error.
+ Unfortunately I (WHN) don't see any simple way to detect this
+ condition in order to issue such an error, so for the meantime
+ SBCL just does this weird broken "conforming" thing.
+
+ The ANSI standard says, in the definition of the special operator
+ MACROLET,
+ The macro-expansion functions defined by MACROLET are defined
+ in the lexical environment in which the MACROLET form appears.
+ Declarations and MACROLET and SYMBOL-MACROLET definitions affect
+ the local macro definitions in a MACROLET, but the consequences
+ are undefined if the local macro definitions reference any
+ local variable or function bindings that are visible in that
+ lexical environment.
+ Then it seems to contradict itself by giving the example
+ (defun foo (x flag)
+ (macrolet ((fudge (z)
+ ;The parameters x and flag are not accessible
+ ; at this point; a reference to flag would be to
+ ; the global variable of that name.
+ ` (if flag (* ,z ,z) ,z)))
+ ;The parameters x and flag are accessible here.
+ (+ x
+ (fudge x)
+ (fudge (+ x 1)))))
+ The comment "a reference to flag would be to the global variable
+ of the same name" sounds like good behavior for the system to have.
+ but actual specification quoted above says that the actual behavior
+ is undefined.
KNOWN BUGS RELATED TO THE IR1 INTERPRETER
;;;
;;; RATIO and BIGNUM are not recognized as numeric types.
-;;; FIXME: It seems to me that this should be set to NIL by default,
-;;; and perhaps not even optionally set to T.
-(defvar *use-implementation-types* t
+;;; FIXME: This really should go away. Alas, it doesn't seem to be so
+;;; simple to make it go away.. (See bug 123 in BUGS file.)
+(defvar *use-implementation-types* t ; actually initialized in cold init
#!+sb-doc
"*USE-IMPLEMENTATION-TYPES* is a semi-public flag which determines how
restrictive we are in determining type membership. If two types are the
this switch is on. When it is off, we try to be as restrictive as the
language allows, allowing us to detect more errors. Currently, this only
affects array types.")
-
(!cold-init-forms (setq *use-implementation-types* t))
;;; These functions are used as method for types which need a complex
;;; part I: TYPEP
(assert (typep #(11) '(simple-array t 1)))
(assert (typep #(11) '(simple-array (or integer symbol) 1)))
-;;; FIXME: broken by 0.pre7.15 #!-SB-INTERPRETER stuff
+;;; FIXME: This is broken because of compiler bug 123: the compiler
+;;; optimizes the type test to T, so it never gets a chance to raise a
+;;; runtime error. (It used to work under the IR1 interpreter just
+;;; because the IR1 interpreter doesn't try to optimize TYPEP as hard
+;;; as the byte compiler does.)
#+nil (assert (raises-error? (typep #(11) '(simple-array undef-type 1))))
(assert (not (typep 11 '(simple-array undef-type 1))))
;;; part II: SUBTYPEP
(FOO 1))"))
-;;; A slightly more complex MACROLET case. In the body of the macro X
-;;; should not be lexically bound. In the body of the macrolet form itself
-;;; X should be bound. Note that THIS CASE WILL CAUSE AN ERROR when it
-;;; tries to macroexpand the call to FOO.
-
-#+nil ; FIXME: broken under 0.pre7.15
+;;; The original PCL documentation for this test said
+;;; A slightly more complex MACROLET case. In the body of the macro
+;;; X should not be lexically bound. In the body of the macrolet
+;;; form itself X should be bound. Note that THIS CASE WILL CAUSE AN
+;;; ERROR when it tries to macroexpand the call to FOO.
+;;;
+;;; This test is commented out in SBCL because ANSI says, in the
+;;; definition of the special operator MACROLET,
+;;; The macro-expansion functions defined by MACROLET are defined
+;;; in the lexical environment in which the MACROLET form appears.
+;;; Declarations and MACROLET and SYMBOL-MACROLET definitions affect
+;;; the local macro definitions in a MACROLET, but the consequences
+;;; are undefined if the local macro definitions reference any
+;;; local variable or function bindings that are visible in that
+;;; lexical environment.
+;;; Since the behavior is undefined, anything we do conforms.:-|
+;;; This is of course less than ideal; see bug 124.
+#+nil
(multiple-value-bind (res cond)
(ignore-errors
(take-it-out-for-a-test-walk
;;; four numeric fields, is used for versions which aren't released
;;; but correspond only to CVS tags or snapshots.
-"0.pre7.14.flaky4.12"
+"0.pre7.14.flaky4.13"
projects / sbcl.git / commitdiff