[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