Faré wrote:
When I try to reproduce compilation of Ilya's system (renaming it undef-var, to prevent any clash) using sbcl-1.2.3.62-989a1d6-linux-x64, 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 SBCL. For SBCL:
; compiling file "/Users/rpg/lisp/asdf/test/fun-with-undefined-locals.lisp" (written 29 OCT 2014 04:59:39 PM):
; /Users/rpg/lisp/asdf/build/fasls/sbcl-1.2.0-macosx-x64/asdf/test/fun-with-undefined-locals-TMP.fasl written ; compilation finished in 0:00:00.001 ;; loading #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?
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 ASDF.
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 standardized.
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.
Best, r
—♯ƒ • 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@dwavesys.com wrote:
"Robert P. Goldman" rpgoldman@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@common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel