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

Faré fahree at gmail.com
Thu Oct 30 11:43:23 UTC 2014

On Wed, Oct 29, 2014 at 11:40 PM, Robert P. Goldman <rpgoldman at sift.info> wrote:
> #P"/Users/rpg/lisp/asdf/build/fasls/sbcl-1.2.0-macosx-x64/asdf/test/fun-with-undefined-locals.fasl"
> ; 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?
Nothing in ASDF should cause an error signal at the end of the W-C-U.
You're discussing the behavior of a file that isn't checked in;
does it have interesting handler-bind's?
Does your SBCL and/or some configuration file include
some interesting patch with respect to W-C-U and/or compile conditions?
(Which version of SBCL is it?)
I don't understand what's going on for you.

>> 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 ;-)
ASDF is a portability layer. It has to handle some non-portability
in underlying implementations and provide portable abstractions.
In this case, how to interpret the return values of COMPILE-FILE
is de facto non-portable, with different implementations having
wildly different interpretations of the CLHS regarding secondary values.
ASDF thus provides the variables *compile-file-warnings-behaviour* and
*compile-file-failure-behaviour* to interpret the warnings-p and failure-p
return values of compile-file. It is *already* a nightmare,
and ASDF has been *solving* that nightmare for a decade. Thanks, danb.

As for fine control of compiler conditions, ASDF doesn't do it,
but it provides hooks in the form of uninteresting-conditions
and compiler-hook. A colleague has written a portability layer
for compiler conditions. I'm hoping he will clean it up and
opensource it at some point.

>> 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).
One reason why I didn't include a test for undefined-variable behavior
in the existing ASDF3 test/test-deferred-warnings.script is precisely
that the way this is treated is highly implentation-dependent, and
I didn't have the time and energy to track down the behavior on 16
implementations and figure out a portability layer or at least a
conditional test.

> 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
No. It doesn't require anything but suitable defaults.
It might "just" be that check-deferred-warnings needs be made more clever,
and/or might need to have its own separate variants of
*compile-file-warnings-behaviour* and *compile-file-failure-behaviour*,
and maybe also *compile-check*.

> 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.
By definition, it's ASDF's job to put the correct W-C-U, and to emulate
a system-wide W-C-U when warnings were deferred in a previous session
(i.e. file "a" was previously compiled with deferred warnings, and least
we forgo all intra-system incrementality, we don't want to recompile it).
The implementation just can't make that stuff up out of thin air.
Hopefully, we don't have to write clever handler-bind's
as part of ASDF itself, but there's a possibility we might,
and indeed someone should look at the undefined-variable behavior on
each and every of the 16 implementations.

> 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
> standardized.
No. The implementation is already doing the deferring or not.
ASDF's job is just to capture the relevant warnings, and either
(1) effectively discard them, which it currently does with its W-C-U,
unless some implementations convert them to errors at the end of W-C-U
and that's a huge incrementality and portability issue that needs be solved
or (2) replay them deterministically at the end of the system's compilation,
which ASDF does when you enable-deferred-warnings-check.

> 4.  It seems like the implementation needs to think carefully about how
> to defer warnings in WITH-COMPILATION-UNIT anyway.
No. We only need worry if some implementations convert warnings to errors
at the end of W-C-U, in which case it becomes much more important to
implement and deploy deferred-warnings.

> 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.
I hope the above explanations help.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Sure, we must render unto Caesar what is due to Caesar. But what is that?
Any and all specie he coined that we possess, or 23 stab wounds?

More information about the asdf-devel mailing list