When compiling this file:

1

;; don't delete the one

(defmethod foo () (call-next-method))

with current SBCL and SLIME, I get this error:

error while parsing arguments to DESTRUCTURING-BIND: invalid number of elements in () to satisfy lambda list ((SWANK-BACKEND::START . SWANK-BACKEND::END)): exactly 1 expected, but 0 found [Condition of type SB-KERNEL::ARG-COUNT-ERROR]

This is the first bit of the backtrace:

Backtrace: 0: (SWANK-BACKEND::SOURCE-PATH-SOURCE-POSITION (0) 1 #<HASH-TABLE :TEST EQ :COUNT 0 {C3C99C9}>) Locals: SB-DEBUG::ARG-0 = (0) SB-DEBUG::ARG-1 = 1 SB-DEBUG::ARG-2 = #<HASH-TABLE :TEST EQ :COUNT 0 {C3C99C9}> [No catch-tags] 1: (SB-DEBUG::TRACE-CALL #<SB-DEBUG::TRACE-INFO SWANK-BACKEND::SOURCE-PATH-SOURCE-POSITION>) 2: (SB-INT:EVAL-IN-LEXENV (SB-DEBUG::TRACE-CALL (QUOTE #<SB-DEBUG::TRACE-INFO SWANK-BACKEND::SOURCE-PATH-SOURCE-POSITION>)) #<NULL-LEXENV>) 3: (SB-IMPL::ENCAPSULATION (0) 1 #<HASH-TABLE :TEST EQ :COUNT 0 {C3C99C9}>) 4: (SWANK-BACKEND::SOURCE-PATH-FILE-POSITION (0) #P"/tmp/foo.lisp") 5: (SWANK-BACKEND::LOCATE-COMPILER-NOTE #P"/tmp/foo.lisp" (0) " 1") 6: (SWANK-BACKEND::COMPILER-NOTE-LOCATION #<SB-C::COMPILER-ERROR-CONTEXT >) 7: (SWANK-BACKEND::SIGNAL-COMPILER-CONDITION #<CODE-DELETION-NOTE {C3AFE59}> #<SB-C::COMPILER-ERROR-CONTEXT >) 8: (SWANK-BACKEND::HANDLE-NOTIFICATION-CONDITION #<CODE-DELETION-NOTE {C3AFE59}>) 9: (SIGNAL #<CODE-DELETION-NOTE {C3AFE59}>) ...

Nearest I can figure, SBCL is generating a code deletion note, and the location is that 1 at the top of the file. In order to find the note in the source file, slime reads the appropriate toplevel form using a special readtable that records the start and end locations of each subform in a hashtable called a source-map. It then looks up the location of the innermost, leftmost subform in the source-map.

I think the problem is that the source location recording readtable only starts recording when it sees a macro character like #(. That's reasonable, because it splits up the subforms. However, #\1 is not a macro character, so nothing is recorded, and the source-map ends up empty.

This is the best fix I could come up with. It's not so hot because the location of the note is not precise, and for some reason that I haven't understood yet, emacs sometimes doesn't underline the note at all. But at least the error is gone, and it doesn't seem to break anything that already worked.

This does seem like an obscure case. I encountered it because of a stray character in a mcclim source file.

Thanks a ton for slime!