Say i have the following (obviously wrong, but let`s for the sake of argument pretend that i didn`t notice) code:
(defstruct foo (bar nil (type (or nil t))))
When i slime-load-file this code i get the following error condition signaled to me via SLDB:
Execution of a form compiled with errors. Form: (DEFSTRUCT FOO (BAR NIL (TYPE (OR NIL T)))) Compile-time-error: (during macroexpansion of (DEFSTRUCT FOO ...)) error while parsing arguments to DESTRUCTURING-BIND: odd number of elements in keyword/value list: ((TYPE (OR NIL T))) [Condition of type SB-INT:COMPILED-PROGRAM-ERROR]
Restarts: 0: [ABORT] Abort SLIME compilation. 1: [ABORT-REQUEST] Abort handling SLIME request. 2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "worker" {B6888B1}>)
Backtrace: 0: ((SB-C::TOP-LEVEL-FORM (ERROR (QUOTE SB-INT:COMPILED-PROGRAM-ERROR) :MESSAGE "(during macroexpansion of (DEFSTRUCT FOO ...)) error while parsing arguments to DESTRUCTURING-BIND: odd number of elements in keyword/value list: ((TYPE (OR NIL T)))" #1="#<...>" . #1#))) 1: (SB-FASL::LOAD-FASL-GROUP #<SB-SYS:FD-STREAM for "file /home/deepfire/source/sdlsq/tmp.fasl" {B6D3F51}>) 2: (SB-FASL::LOAD-AS-FASL #<SB-SYS:FD-STREAM for "file /home/deepfire/source/sdlsq/tmp.fasl" {B6D3F51}> NIL #<unavailable argument>) 3: (SB-FASL::INTERNAL-LOAD #P"/home/deepfire/source/sdlsq/tmp.fasl" #P"/home/deepfire/source/sdlsq/tmp.fasl" :ERROR NIL NIL :BINARY NIL) 4: (SB-FASL::INTERNAL-LOAD #P"/home/deepfire/source/sdlsq/tmp.fasl" #P"/home/deepfire/source/sdlsq/tmp.fasl" :ERROR NIL NIL NIL :DEFAULT) 5: (LOAD #P"/home/deepfire/source/sdlsq/tmp.fasl")
...
So, what is the problem with that?
Thing is, you my argue that the error specification is precise enough.
However if i want to jump to the source code location which caused this error, after striking 'v' on /any/ entry in the debug stack, i get errors like this:
unhandled DEBUG-CONDITION: #<SB-DI::COMPILED-DEBUG-FUN (SB-C::TOP-LEVEL-FORM (ERROR (QUOTE SB-INT:COMPILED-PROGRAM-ERROR) :MESSAGE "(during macroexpansion of (DEFSTRUCT FOO ...)) error while parsing arguments to DESTRUCTURING-BIND: odd number of elements in keyword/value list: ((TYPE (OR NIL T)))" #1="#<...>" . #1#))> has no debug-block information.
In fact, observing the debug stack makes it clear that none of its entries bear direct relevance to the source at fault. It points into the guts of the SBCL macroexpander.
So this raises the question -- how do i jump to the source location of a syntax error?
regards, Samium Gromoff