[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSoC project - Improving ELisp Traceback and Debugging Information

From: Helmut Eller
Subject: Re: GSoC project - Improving ELisp Traceback and Debugging Information
Date: Sat, 06 Jun 2020 21:56:41 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

> I'll be looking at how other Lisp compilers record source code
> locations. SBCL is what I'm most familiar with but that compiler is
> very
> complex, and uses an intermediate code representation during
> compilation
> that makes recording this type of information easier.

[For now lets pretend that "source-path" is the same as a

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

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.

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]