unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Helmut Eller <eller.helmut@gmail.com>
To: Zach Shaftel <zshaftel@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: GSoC project - Improving ELisp Traceback and Debugging Information
Date: Sat, 06 Jun 2020 21:56:41 +0200	[thread overview]
Message-ID: <m2mu5gvuh2.fsf@gmail.com> (raw)
In-Reply-To: <878sh0rr7m.fsf@gmail.com> (Zach Shaftel's message of "Sat, 06 Jun 2020 14:20:46 -0400")

> 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
source-location.]

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

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.

Helmut



  reply	other threads:[~2020-06-06 19:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-03 21:42 GSoC project - Improving ELisp Traceback and Debugging Information Zach Shaftel
2020-06-05  7:00 ` Helmut Eller
2020-06-06 18:20   ` Zach Shaftel
2020-06-06 19:56     ` Helmut Eller [this message]
2020-06-06 23:18       ` Zach Shaftel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2mu5gvuh2.fsf@gmail.com \
    --to=eller.helmut@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=zshaftel@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).