[slime-devel] slime2 vs. syntax errors

[Helmut Eller]

* Samium Gromoff [2006-04-23 20:26+0200] writes:

> 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.

Those are actually the guts of the loader, not the macroexpander.
AFAIK, SBCL still generates code for source with this kind of error
but the code just signals the condition.

It might help, if you use slime-compile-file (without loading) so that
you can see the compiler messages without getting disturbed by the
errors during load time.

> So this raises the question -- how do i jump to the source location of a
> syntax error?

Well, SBCL doesn't provide the source location for those errors so
SLIME can't display it.

Below is a little patch to SBCL to pass the source context along.

If you are debugging your own (toplevel) macros, it often useful to
eval (instead of compile) the code, because then the compiler doesn't
catch the error and you can jump to the source of the macro expander
from the backtrace.

Helmut.


--- sbcl-0.9.11/src/compiler/main.lisp  2005-11-21 04:53:21.000000000 +0100
+++ /tmp/main-patched.lisp      2006-04-24 23:24:57.384035032 +0200
@@ -1185,7 +1185,9 @@
                  ;; sequence of steps in ANSI's "3.2.3.1 Processing of
                  ;; Top Level Forms".
                  #-sb-xc-host
-                 (let ((expanded (preprocessor-macroexpand-1 form)))
+                 (let ((expanded 
+                       (let ((*current-path* path))
+                         (preprocessor-macroexpand-1 form))))
                    (cond ((eq expanded form)
                           (when compile-time-too
                             (eval-in-lexenv form *lexenv*))