[asdf-devel] deferred warnings doesn't tell which file

Faré fahree at gmail.com
Tue Oct 29 16:25:36 UTC 2013


Dear Attila,

> so, i'm using deferred warnings, because warnings are useful!
>
I'm glad this functionality now has a user outside ITA!

I wanted to enable it by default in ASDF 3, but that broke too many
packages in Quicklisp (~50), half of which don't have a responsive
maintainer to fix the issue (they still haven't responded to the bug
report eight months later).

> the only problem is that, in this specific case, i get the following
> after compilation has finished:
>
>
> ; compilation finished in 0:00:00.033
> ; in: LAMBDA (SB-PCL::.METHOD-ARGS. SB-PCL::.NEXT-METHODS.)
> ;     (SB-MOP:SLOT-VALUE-USING-CLASS # HU.DWIM.PEREC::INSTANCE ...)
> ;
> ; caught WARNING:
> ;   undefined variable: HU.DWIM.PEREC::INSTANCE
> ;
> ; compilation unit finished
> ;   Undefined variable:
> ;     HU.DWIM.PEREC::INSTANCE
> ;   caught 1 WARNING condition
> ;
> ; compilation unit aborted
> ;   caught 4 fatal ERROR conditions
>
>
> and it doesn't even tell which file it happened with. (this error comes
> from the depths of sbcl internals around generic methods).
>
> how was it meant to work originally? is it assumed that the warning
> will always contain a name or something that helps identifying where
> it comes from? if so, then it's not always the case, and when warnings
> are not deferred at least the current toplevel form is visible in the
> output.
>
> note: this is not a showstopper just an inconvenience. i can identify
> the file by checking the *.sbcl-warnings files manually.
>
If you look in uiop/lisp-build.lisp, functions reify-undefined-warning
and unreify-undefined-warning, you'll see that we're trying to save
and restore file context information; I don't know whether or not
we're failing to save and restore it, or SBCL is failing to display it
after we restore the data (you could try to disable the deferred
warning mechanism, and see how it behaves — if it then displays file
information, that's a UIOP failure; if it doesn't, probably an SBCL
failure).

If it's a UIOP failure, patches are welcome. If it's a SBCL failure,
SBCL may or may not accept patches, and UIOP will accept a workaround
if SBCL refuses a patch.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Failure is not an option. It comes bundled with your Microsoft product.
        — Ferenc Mantfeld



More information about the asdf-devel mailing list