Tony Martinez <tonyms@...> writes:
> * (handler-case
> (with-input-from-string (*query-io* " no")
> (simple-type-error () 'error))
> ; in: LAMBDA NIL
> ; (SB-KERNEL:FLOAT-WAIT)
> ; note: deleting unreachable code
> ; compilation unit finished
> ; printed 1 note
> Should this note be printed? The HANDLER-CASE expansion introduces
> the (FLOAT-WAIT) call. Are implementation-disclosing notes bugs?
It probably shouldn't be printed, but fixing it is a little nasty.
This is related to bug #238, and is an artefact of our implementation
of EVAL. The point is that, when deciding whether or not to print
code deletion notes, the system has a heuristic to see whether the
form in question existed in the original code, and only if so, print
Clearly, (SB-KERNEL:FLOAT-WAIT) doesn't appear in your original code.
The problem is that it _does_ appear in the original code as seen by
the compiler, because the first stage of evaluation is a fair amount
of macroexpansion. By the time the compiler proper sees the code,
it's been macroexpanded to something that does contain
SB-KERNEL:FLOAT-WAIT, and so when it deletes that clause, it does
trigger the heuristic and the note is printed.
So, to fix this (and bug #238) the compiler needs to be notified a
little bit more about what the original source actually was. Sadly,
it's a little trickier that one might expect, because of the need to
get the top-level semantics of PROGN, SYMBOL-MACROLET and friends
right -- one can't just feed the original expression into the compiler
In any case, I'll add this report to bug 238.
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)