forever, even when it is uninterned and all other references to it
are lost.
-141:
- Pretty-printing nested backquotes doesn't work right, as
- reported by Alexey Dejneka sbcl-devel 2002-01-13:
- * '``(FOO ,@',@S)
- ``(FOO SB-IMPL::BACKQ-COMMA-AT S)
- * (lisp-implementation-version)
- "0.pre7.129"
+141: "pretty printing and backquote"
+ a.
+ * '``(FOO ,@',@S)
+ ``(FOO SB-IMPL::BACKQ-COMMA-AT S)
+
+ b.
+ * (write '`(, .ala.) :readably t :pretty t)
+ `(,.ALA.)
+
+ (note the space between the comma and the point)
+
143:
(reported by Jesse Bouwman 2001-10-24 through the unfortunately
code. Since then the warning has been downgraded to STYLE-WARNING,
so it's still a bug but at least it's a little less annoying.
-178: "AVER failure compiling confused THEs in FUNCALL"
- In sbcl-0.7.4.24, compiling
- (defun bug178 (x)
- (funcall (the function (the standard-object x))))
- gives
- failed AVER:
- "(AND (EQ (IR2-CONTINUATION-PRIMITIVE-TYPE 2CONT) FUNCTION-PTYPE) (EQ CHECK T))"
- This variant compiles OK, though:
- (defun bug178alternative (x)
- (funcall (the nil x)))
-
- (since 0.7.8.9 it does not signal an error; see also bug 199)
-
183: "IEEE floating point issues"
Even where floating point handling is being dealt with relatively
well (as of sbcl-0.7.5, on sparc/sunos and alpha; see bug #146), the
inaccurate transformations.
* Alexey Dejneka pointed out that
(IGNORE-ERRORS (IDENTITY (THE REAL '(1 2 3))))
- works as it should. Also
+ and
(IGNORE-ERRORS (VALUES (THE REAL '(1 2 3))))
- works as it should. Perhaps this is another case of VALUES type
- intersections behaving in non-useful ways?
-
-199: "hairy FUNCTION types confuse the compiler"
- (reported by APD sbcl-devel 2002-09-15)
- (DEFUN MUR (F)
- (EQ NIL (FUNCALL F)))
-
- (DEFUN FOO (F X)
- (DECLARE (TYPE (AND FUNCTION (SATISFIES MUR)) F))
- (FUNCALL F X))
-
- fails to compile, printing
- failed AVER:
- "(AND (EQ (IR2-CONTINUATION-PRIMITIVE-TYPE 2CONT) FUNCTION-PTYPE) (EQ CHECK T))"
-
- APD further reports that this bug is not present in CMUCL.
-
- (this case was fixed in 0.7.8.9; see also bug 178)
+ work as they should.
201: "Incautious type inference from compound CONS types"
(reported by APD sbcl-devel 2002-09-17)
(the integer (helper))
nil)
- Type check for INTEGER is inserted, the result of which serves as
- the first argument of M-V-C, is inserted after evaluation of NIL. So
- arguments of M-V-C are pushed in the wrong order. As a temporary
- workaround type checking was disabled for M-V-Cs in 0.7.9.13. A
- better solution would be to put a check between evaluation of
- arguments, but it could be tricky to check result types of PROG1, IF
- etc.
-
-223: "(SETF FDEFINITION) and #' semantics broken for wrappers"
- Although this
- (defun foo (x)
- (print x))
- (defun traced (fn)
- (lambda (&rest rest)
- (format t "~&about to call ~S on ~S~%" fn rest)
- (apply fn rest)
- (format t "~&returned from ~S~%" fn)))
- (setf (fdefinition 'foo)
- (traced #'foo))
- (foo 11)
- does what one would expect, this
- (defun bar (x)
- (print x))
- (let ((bar0 #'bar))
- (setf (fdefinition 'bar)
- (lambda (&rest rest)
- (format t "~&about to enter BAR ~S~%" rest)
- (apply bar0 rest)
- (format t "~&back from BAR~%"))))
- (bar 12)
- recurses endlessly in sbcl-0.7.9.32. (Or it works if #' and
- FDEFINITION are replaced by SYMBOL-FUNCTION.)
+ Type check for INTEGER, the result of which serves as the first
+ argument of M-V-C, is inserted after evaluation of NIL. So arguments
+ of M-V-C are pushed in the wrong order. As a temporary workaround
+ type checking was disabled for M-V-Cs in 0.7.9.13. A better solution
+ would be to put the check between evaluation of arguments, but it
+ could be tricky to check result types of PROG1, IF etc.
228: "function-lambda-expression problems"
in sbcl-0.7.9.6x, from the REPL:
229:
(subtypep 'function '(function)) => nil, t.
-230:
- (fixed in 0.7.10.5)
+233:
+ Bug in constraint propagation:
+
+ (defun foo (x)
+ (declare (optimize (speed 2) (safety 3)))
+ (let ((y 0d0))
+ (values
+ (the double-float x)
+ (setq y (+ x 1d0))
+ (setq x 3d0)
+ (quux y (+ y 2d0) (* y 3d0)))))
+ (foo 4) => segmentation violation
+
+ (see usage of CONTINUATION-ASSERTED-TYPE in USE-RESULT-CONSTRAINTS)
+
+234:
+ clocc-ansi-test :EXCEPSIT-LEGACY-1277 fails in sbcl-0.7.10.33
+
+ In sbcl-0.7.10.33 (but not ca. 0.7.10.29),
+ (defclass foo54 () ())
+ (reinitialize-instance (make-instance 'foo54) :dummy 0)
+ does not signal an error. ANSI's definition of REINITIALIZE-INSTANCE
+ says
+ The system-supplied primary method for REINITIALIZE-INSTANCE signals
+ an error if an initarg is supplied that is not declared as valid.
+ and defines what that means in
+ 7.1.2 Declaring the Validity of Initialization Arguments
+ In effect, even though the signature shown for the REINITIALIZE-INSTANCE
+ gf in its ANSI definition page is &ALLOW-OTHER-KEYS, and that might
+ make it look as though anything goes, the gf+methods ensemble is required
+ to have more complicated &KEY-checking behavior than that.
DEFUNCT CATEGORIES OF BUGS
IR1-#:
projects / sbcl.git / blobdiff