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

[Faré]

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
> ; in: DEFUN FUN-WITH-UNDEFINED-LOCALS-PACKAGE::FOO
> ;     (+ FUN-WITH-UNDEFINED-LOCALS-PACKAGE::A
> FUN-WITH-UNDEFINED-LOCALS-PACKAGE::B)
> ;
> ; 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:
> ;     FUN-WITH-UNDEFINED-LOCALS-PACKAGE::A
> FUN-WITH-UNDEFINED-LOCALS-PACKAGE::B
> ;   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
> ASDF.
>
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?