According to <http://alfa.s145.xrea.com/sbcl/solaris-x86.html>, the
stack exhaustion checking (implemented with a write-protected guard
page) does not work on SunOS/x86.
+
+387:
+ 12:10 < jsnell> the package-lock test is basically due to a change in the test
+ behaviour when you install a handler for error around it. I
+ thought I'd disabled the test for now, but apparently that was
+ my imagination
+ 12:19 < Xophe> jsnell: ah, I see the problem in the package-locks stuff
+ 12:19 < Xophe> it's the same problem as we had with compiler-error conditions
+ 12:19 < Xophe> the thing that's signalled up and down the stack is a subtype of
+ ERROR, where it probably shouldn't be
package-lock-violation))))
;;;; Program-errors from lexical violations
-(reset-test)
-(set-test-locks t)
-(dolist (pair *illegal-compile-time-forms-alist*)
- (destructuring-bind (sym . form) pair
+;;;; In addition to that, this is also testing for bug 387
+(with-test (:fails-on :sbcl)
+ (reset-test)
+ (set-test-locks t)
+ (dolist (pair *illegal-compile-time-forms-alist*)
+ (destructuring-bind (sym . form) pair
(declare (ignore sym))
- (let ((fun (compile nil `(lambda ()
- ,form))))
- (assert (raises-error? (funcall fun) program-error)))))
+ (let ((fun (compile nil `(lambda ()
+ ,form))))
+ (assert (raises-error? (funcall fun) program-error))))))
;;;; See that trace on functions in locked packages doesn't break
;;;; anything.
(ecase (first fail)
(:expected-failure "Expected failure:")
(:unexpected-failure "Failure:")
- (:unexpected-success "Unexcepted success:"))
+ (:unexpected-success "Unexpected success:"))
(enough-namestring (second fail))
(third fail))))))
(t
;;; 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.4.9"
+"0.9.4.10"