Re: GSoC project - Improving ELisp Traceback and Debugging Information

[Zach Shaftel <zshaftel@gmail.com>]

> Before converting to IR1, SBCL records the "source-path" of each cons
> cell in a top-level form in the hash table *SOURCE-PATHS*.  (See the
> function SUB-FIND-SOURCE-PATHS defined in ir1tran.lisp).

Ah okay, I guess I'm not as familiar with the SBCL compilation process
as I thought. I had some trouble finding where the source path recording
actually takes place so thanks for pointing that out, gonna be doing a
lot more digging through the source.

> Later, when the compiler walks down the (macroexpanded) form, it
> searches the recorded source-path for the current form. If something
> is recorded, good; if nothing is recorded, then the compiler uses the
> source-path of the parent form instead (the top-level form has always
> a recorded source-path).
>
> I think this approach is quite simple and usually works pretty well.
> Most macros return part of the input arguments somewhere in their output
> and so the compiler will naturally find the recorded source-path in the
> hash table.  Problematic are macros that completely copy/rewrite the
> input.  Luckily, such macros are rare.

Great, that certainly does sound like something the byte compiler can
manage to keep track of.

> I don't know if it would work well enough for macroexpand-all and
> cconv.el.  But at least, it doesn't need new data types.  It could also
> help to manually propagate the source locations in a few places, like
> macroexp--cons.

That seems like a good approach and should be easy enough, and luckily
macroexp--expand-all already tries hard to preserve `eq`uality of
expanded forms. cconv.el might be the bigger issue, but that's a task
for later.

-Zach