Fix LET-CONVER[ST]ION confusion.
... also adjust ctor commentary to reflect disappearance of
INSTANCE-LAMBDA.
(when (leaf-has-source-name-p clambda)
;; ANSI requires that explicit NOTINLINE be respected.
(or (eq (lambda-inlinep clambda) :notinline)
- ;; If (= LET-CONVERTION 0) we can guess that inlining
+ ;; If (= LET-CONVERSION 0) we can guess that inlining
;; generally won't be appreciated, but if the user
;; specifically requests inlining, that takes precedence over
;; our general guess.
- (and (policy clambda (= let-convertion 0))
+ (and (policy clambda (= let-conversion 0))
(not (eq (lambda-inlinep clambda) :inline))))))
;;; We also don't convert calls to named functions which appear in the
(setf (ctor-class ctor) class)
(pushnew ctor (plist-value class 'ctors))
(setf (funcallable-instance-fun ctor)
- ;; KLUDGE: Gerd here has the equivalent of (COMPILE NIL
- ;; (CONSTRUCTOR-FUNCTION-FORM)), but SBCL's COMPILE doesn't
- ;; deal with INSTANCE-LAMBDA expressions, only with LAMBDA
- ;; expressions. The below should be equivalent, since we
- ;; have a compiler-only implementation.
- ;;
- ;; (except maybe for optimization qualities? -- CSR,
- ;; 2004-07-12)
- ;;
- ;; FIXME: INSTANCE-LAMBDA is no more. We could change this.
(multiple-value-bind (form locations names)
(constructor-function-form ctor)
(apply (compile nil `(lambda ,names ,form)) locations)))))
(assert (raises-error? (bug231b 0 0) type-error))
;;; A bug appeared in flaky7_branch. Python got lost in unconverting
-;;; embedded tail calls during let-convertion.
+;;; 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))
;;; checkins which aren't released. (And occasionally for internal
;;; versions, especially for internal versions off the main CVS
;;; branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".)
-"0.9.3.54"
+"0.9.3.55"