libera/#sbcl - IRC Chatlog
Search
14:49:28
dim
https://github.com/dimitri/pgloader/issues/1407 has a new issue with SBCL 2.2.6: An unhandled error condition has been signalled: deleting unreachable code
14:50:02
dim
pgloader compiles lisp code at run-time (parses its own command language with esrap, generating lisp code, compiles it and calls the function object at run-time)
15:12:50
Krystof
you're probably generating clauses that sbcl can prove will never be reached; sbcl might have got marginally smarter in the last three months
15:13:36
Krystof
as Shinmera says, maybe you are catching general conditions, because that should be signalled as a compiler note (specifically a sb-ext:code-deletion-note IIRC)
15:16:43
Krystof
you have several usages of (handler-case <form> (condition (c) ...)) which will in general catch all sorts of non-important conditions
15:18:23
Krystof
you could also muffle sb-ext:compiler-note around the bit that invokes the compiler on the generated lisp code, which would solve the immediate problem, but handling all kinds of `condition` is potentially fragile
15:19:28
Krystof
one idiom for handlers is to resignal conditions to see if an outer handler wants to handle them, and if not to handle themselves. Something like (handler-bind ((foo-condition (lambda (c) (signal c) <handle-it>))) ...)
15:20:00
Krystof
if you have an outer handler handling all kinds of condition, the inner handler will transfer responsibility to your outer handler and your outer handler will say, "welp, fatal error"
15:21:16
Krystof
if the reason for handling all these conditions is to avoid popping up the lisp debugger, you could also consider customizing *debugger-hook* instead