[Top][All Lists]

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

Re: Skipping unexec via a big .elc file

From: Alan Mackenzie
Subject: Re: Skipping unexec via a big .elc file
Date: Sat, 14 Jan 2017 11:26:58 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

Hello, Eli.

On Sat, Jan 14, 2017 at 01:07:17PM +0200, Eli Zaretskii wrote:
> > From: Andreas Schwab <address@hidden>
> > Cc: Ken Raeburn <address@hidden>,  address@hidden,  address@hidden
> > Date: Sat, 14 Jan 2017 11:55:42 +0100

> > On Jan 14 2017, Eli Zaretskii <address@hidden> wrote:

> > > The line number in the error message is bogus, it points to a require
> > > line (that's a known issue with byte-compiler error reporting, I
> > > think).

> > It's not bogus, since the error was raised while the byte-compiler
> > evaluated the form there.

> It's "bogus" in the sense that it isn't useful for finding the code
> which triggered the error.

Just as a matter of interest, I spent quite a bit of time in the summer
trying to fix this.  My approach was this:
(i) The modified reader created an association list between each cons it
  creates and the source code position.
(ii) Each time a compiler function transformed such a cons, instead of
  the function returning the transformed form, it did setcar/setcdr into
  the original cons to preserve the mapping in the association table.
(iii) On emitting an error/warning, the compiler would look up the
  source code position in the association list.

I'm confident that such an approach would work.  However, it was an
enormous amount of work to adapt the compiler, and I got distracted by
other things, so haven't managed to produce anything workable, yet.  At
least there's already a reliable test suite for this, namely make
bootstrap.  :-)

Alan Mackenzie (Nuremberg, Germany).

reply via email to

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