> When there are nested COMPILE-FILE calls, we --since forever--
> propagate failures to the outermost COMPILE-FILE call. I used to
> believe this was correct, but now I'm getting doubts, and I cannot
> seem to find a place in the spec that _requires_ this behaviour. We
> are also not quite consistent in the propagation.
>>From a practical point of view, consider this:
> ;; good.lisp
> (eval-when (:compile-toplevel)
> ;; Compiling bad.lisp fails
> (multiple-value-bind (fasl warn fail) (compile-file "bad.lisp")
> (declare (ignore warn))
> (if fail
> (error "Compiling bad.lisp failed!")
> (load fasl))))
> (defun good () 42)
> If compiling bad.lisp causes a full WARNING, eg.:
> (defun bad () (nil))
> it is percolated to compilation of good.lisp and the (COMPILE-FILE
> "bad.lisp") returns a tertiary value of NIL -- and bad.fasl is loaded!
I'm not sure of the practical value of failing when a warning
is encountered here, but the spec for COMPILE-FILE clearly says:
The tertiary value, failure-p, is false if no conditions of
type error or warning (other than style-warning) were detected
by the compiler, and true otherwise.
So SBCL seems to be violating the spec with its current behavior.