;;;; While most of SBCL is derived from the CMU CL system, the test
;;;; files (like this one) were written from scratch after the fork
;;;; from CMU CL.
-;;;;
+;;;;
;;;; This software is in the public domain and is provided with
;;;; absolutely no warranty. See the COPYING and CREDITS files for
;;;; more information.
(declaim (ftype (function (real) (values integer single-float)) valuesify))
(defun valuesify (x)
(values (round x)
- (coerce x 'single-float)))
+ (coerce x 'single-float)))
(defun exercise-valuesify (x)
(multiple-value-bind (i f) (valuesify x)
(declare (type integer i))
(0 "GMT" . "GDT") (-2 "MET" . "MET DST"))
"*The string representations of the time zones.")
+(declaim (optimize (debug 1) (speed 1) (space 1)))
+
;;; The old CMU CL Python compiler assumed that it was safe to infer
;;; function types (including return types) from function definitions
-;;; and then use them to optimize code later. This is of course bad
-;;; when functions are redefined. The problem was fixed in
-;;; sbcl-0.6.12.57.
+;;; and then use them to optimize code later [and it was almost
+;;; right!]. This is of course bad when functions are redefined. The
+;;; problem was fixed in sbcl-0.6.12.57.
(defun foo (x)
- (if (plusp x)
- 1.0
- 0))
-(defun bar (x)
- (typecase (foo x)
- (fixnum :fixnum)
- (real :real)
- (string :string)
- (t :t)))
+ (if (plusp x)
+ 1.0
+ 0))
+(eval '(locally
+ (defun bar (x)
+ (typecase (foo x)
+ (fixnum :fixnum)
+ (real :real)
+ (string :string)
+ (t :t)))
+ (compile 'bar)))
(assert (eql (bar 11) :real))
(assert (eql (bar -11) :fixnum))
(setf (symbol-function 'foo) #'identity)
;;; bug 31 turned out to be a manifestation of non-ANSI array type
;;; handling, fixed by CSR in sbcl-0.7.3.8.
(defun array-element-type-handling (x)
+ (declare (optimize safety))
(declare (type (vector cons) x))
(when (consp (aref x 0))
(aref x 0)))
-(assert (eq (array-element-type-handling
- (make-array 3 :element-type t :initial-element 0))
- nil))
+(assert (raises-error?
+ (array-element-type-handling
+ (make-array 3 :element-type t :initial-element 0))
+ type-error))
;;; bug 220: type check inserted after all arguments in MV-CALL caused
;;; failure of stack analysis
(assert (raises-error? (bug231b 0 1.5) type-error))
(assert (raises-error? (bug231b 0 0) type-error))
-(sb-ext:quit :unix-status 104) ; success
+;;; A bug appeared in flaky7_branch. Python got lost in unconverting
+;;; embedded tail calls during let-conversion.
+(defun bug239 (bit-array-2 &optional result-bit-array)
+ (declare (type (array bit) bit-array-2)
+ (type (or (array bit) (member t nil)) result-bit-array))
+ (unless (simple-bit-vector-p bit-array-2)
+ (multiple-value-call
+ (lambda (data1 start1)
+ (multiple-value-call
+ (lambda (data2 start2)
+ (multiple-value-call
+ (lambda (data3 start3)
+ (declare (ignore start3))
+ (print (list data1 data2)))
+ (values 0 0)))
+ (values bit-array-2 0)))
+ (values 444 0))))
+(assert (equal (bug239 (make-array 4 :element-type 'bit
+ :adjustable t
+ :initial-element 0)
+ nil)
+ '(444 #*0000)))
+
+(defstruct some-structure a)
+(eval-when (:compile-toplevel)
+ ;; in the big CLASS reorganization in pre8, this would fail with
+ ;; SOME-STRUCTURE-A is not FBOUNDP. Fixed in 0.pre8.64
+ (find-class 'some-structure nil))
+(eval-when (:load-toplevel)
+ (assert (typep (find-class 'some-structure) 'class)))