[Asdf-devel] ASDF does not signal deferred non-style warnings as an error

Robert P. Goldman rpgoldman at sift.info
Thu Oct 30 03:40:17 UTC 2014

Faré wrote:
> When I try to reproduce compilation of Ilya's system (renaming it
> undef-var, to prevent any clash) using
> sbcl-, it "works" exactly as expected:
> 1- if deferred warnings are disabled (the default), then the
> compilation succeeds, and I get an undefined variable warning at the
> end of the build but that doesn't cause a build failure, because
> operate's with-compilation-unit doesn't catch these warnings (and
> can't replay those from previous sessions, anyway).

Interesting.  My test seems to show the build failing, on both ACL and

; compiling file
"/Users/rpg/lisp/asdf/test/fun-with-undefined-locals.lisp" (written 29
OCT 2014 04:59:39 PM):

; compilation finished in 0:00:00.001
;; loading

; file: /Users/rpg/lisp/asdf/test/fun-with-undefined-locals.lisp
; caught WARNING:
;   undefined variable: FUN-WITH-UNDEFINED-LOCALS-PACKAGE::A
; caught WARNING:
;   undefined variable: FUN-WITH-UNDEFINED-LOCALS-PACKAGE::B
; compilation unit finished
;   Undefined variables:
;   caught 2 WARNING conditions
; compilation unit aborted
;   caught 2 fatal ERROR conditions
Expected error type: COMPILE-FAILED-ERROR
Script succeeded
Using sbcl, test-deferred-warnings.script passed

How do you distinguish between the build failing and succeeding but
being followed by an error signal?
> 2- if deferred warnings are enabled via
> (uiop:enable-deferred-warnings), then the compilation fails while
> perform'ing a compile-op on the system, because it replays the
> undefined-warnings and checks that the variable still doesn't exist
> afterwards.
> It could be argued that undefined-variable warnings, unlike
> undefined-function warnings, should not be deferrable, and that it's
> always a warning to use a special variable that wasn't declared as
> such. But that's not what SBCL does.
> I can't explain why you have a different result, unless your setup
> somehow configures some conditions as uninteresting.
> On the other hand, differences between compilers easily explain
> variations between condition reported by ASDF, since they depend both
> on what conditions the compiler reports, that are not portable, and on
> the *compile-file-warnings-behaviour* and
> *compile-file-failure-behaviour* values, that are also unportable.
> Note that unless you :force t, non-fatal warnings can disappear the
> second time around.

It is the "not portable" part of this that makes it seem like a
maintenance nightmare, and not ASDF's job. If SBCL wants to signal
warnings at oddball times, that's too bad, but I don't see that it's
ASDF's job to fix that.  We have to leave some fun for the SBCL
maintainers ;-)
> NB: Back when I first pre-released ASDF3, I wanted to enable
> deferred-warnings by default, but this turned out to be a
> community-wide coordination nightmare, and I had to bail out. If
> someone wants to make it happen, he'll have to make sure that it
> doesn't break quicklisp and then still have to convince the community
> and the ASDF maintainer that the change is worth it and that enough
> publicity is made that random users don't get badly surprised.

My experience with the deferred warnings on Allegro left me deeply
dissatisfied. ACL seems to deal with deferring warnings to the right
place simply through use of WITH-COMPILATION-UNIT.  In particular, it
correctly waits on UNDEFINED-FUNCTION warnings until the whole
compilation unit has been processed, yet I don't recall delays in seeing
UNDEFINED-VARIABLE references (I should check to confirm this, but I
feel sure I would have noticed if undefined lexical variable warnings
were deferred till the end of the build).

This suggested some conjectures:

1.  AFAICT, using ASDF's deferred-warnings would have required first
breaking the logic that ACL already provides, and then recreating it in

2.  If ACL can handle this sensibly w/o requiring any outside assistance
from ASDF, then I don't believe that this should be ASDF's job.

3.  The job of deferring warnings properly seems to involve thinking
hard about which warnings should and should not be deferred. That's
something that the implementation's maintainers will always be able to
do better than we can, since the condition classes are poorly

4.  It seems like the implementation needs to think carefully about how
to defer warnings in WITH-COMPILATION-UNIT anyway.

I believe that you had a reason that you disliked W-C-U, but I'm afraid
I would have to go back and recover that argument.


> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
> The meta-Turing test counts a thing as intelligent if it seeks to apply
> Turing tests to objects of its own creation.
>                 — Lew Mammel, Jr.
> On Wed, Oct 29, 2014 at 6:27 PM, Ilya Perminov <iperminov at dwavesys.com> wrote:
>> "Robert P. Goldman" <rpgoldman at sift.info> writes:
>>> I cannot replicate this, but this may be a new behavior introduced by
>>> recent changes to SBCL, and I'm not on the latest release yet.
>> Very strange. I can reproduce the problem with all the SBCL versions I
>> have: 1.1.4, 1.1.18, 1.2.4. SBCL 1.2.4 includes the latest version of
>> ASDF. Do you see any difference in behavior between deferred and normal
>> warnings, i.e. (defun foo () (+ a b)) vs (defun foo () (foo 3))?
>> _______________________________________________
>> Asdf-devel mailing list
>> Asdf-devel at common-lisp.net
>> http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

More information about the asdf-devel mailing list