[Sbcl-devel] COMPILE-FILE handling of errors

[Nikodemus S. <nik...@ra...>]

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!

If bad.lisp on the other hand causes a bona fide ERROR, eg.:

((bogus))

then the (COMPILE-FILE "bad.lisp") returns a tertiary value of T.

In the very least both of these should behave identically.

Moreover percolating the error upwards serves no purpose that I can
see -- it only subverts the tertiary return value of COMPILE-FILE.

If *both* calls returned a tertiary value of T, that would seem
somewhat better to me, but even that only seems to make life harder
when there are nested COMPILE-FILE calls.

Any thoughts on this?

Cheers,

 -- Nikodemus