[slime-devel] #+#. bug report (with fix, maybe)

Luis Oliveira luismbo at gmail.com
Tue Jan 22 00:33:31 UTC 2008


Hello,

While trying to compile some code that contained the #+#. idiom I came
across a bug in SLIME.  Here's a minimal test case:

  (defun foo ()
    #+#.'(:and) (/ 1 0))

And some variations:

  (defun foo ()
    #+#.'(:and) t
    (/ 1 0))

  (defun foo ()
    (let (unused)
      #+#.'(:and) t))

Trying to compile these examples through, e.g., slime-compile-file or
slime-compile-defun results in a cryptic error:

  unknown operator in feature expression: (#:|#.1|).
    [Condition of type SIMPLE-ERROR]

What these three examples have in common is that a compiler note is
generated and the offending form contains #+#. which makes
SWANK-BACKEND::LOCATE-COMPILER-NOTE choke.  What happens is that
READ-AND-RECORD-SOURCE-MAP overrides #. and makes it return a gensym,
#:|#.1| in this particular example, which is then passed to #+ and
causes the error above.

SUPPRESS-SHARP-DOT sets things up so that #. returns a gensym instead of
NIL in order to "avoid multiple entries for nil at toplevel in the
source-map", according to the ChangeLog. Even if we ignore that problem,
having #. return NIL in this case, while it would dodge the error, it
wouldn't find or properly annotate the offending (/ 1 0) form since
#+cl:nil usually suppresses forms.

The attached patch gets rid of SUPPRESS-SHARP-DOT. That not only fixes
my original problem but also makes the following example work better
than it before, since the (/ 1 0) form is now annotated:

  #.'(defun foo () (/ 1 0))

I believe that was the case the ChangeLog entry I quoted was referring
to. However, I have the feeling that there might be some good reason why
#. was suppressed in the first place. Any ideas?


(BTW, it took me a while to figure out this bug was coming from within
SLIME itself, and it might have taken even longer if someone hadn't
noticed that compiling the software in question without SLIME worked
without problem. Perhaps it would be helpful to somehow report internal
errors as such?)

-- 
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: slime-dont-suppress-sharp-dot.diff
Type: text/x-patch
Size: 2625 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/slime-devel/attachments/20080122/71295c30/attachment.bin>


More information about the slime-devel mailing list