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