[Top][All Lists]

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

Re: Thoughts on getting correct line numbers in the byte compiler's warn

From: Alan Mackenzie
Subject: Re: Thoughts on getting correct line numbers in the byte compiler's warning messages
Date: Fri, 16 Nov 2018 14:14:45 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

Hello, Stefan.

On Thu, Nov 15, 2018 at 13:01:49 -0500, Stefan Monnier wrote:
> >> Maybe the "big cons-cells" approach is not that bad after all, since it
> >> doesn't try to introduce new objects which are "equal but not": it just
> >> introduces a subtype of cons-cells and that's that, so it's semantically
> >> much simpler/cleaner.

> > I'm not sure about that.  We'd still have to modify EQ to cope with the
> > new structure no matter how we do it.

> No need to modify EQ for the big-cons cells: a big-cons-cell would be
> a normal cons-cell just with more fields added at its end.  It's not
> a "location + pointer to the real object" like we need to do for
> symbols, so EQ will do the expected thing on it.

Sorry, yes.  We'd need some way of distinguishing between the two types
of cons cell (which I think you already dealt with some while ago) and
we'd need to do an awful lot of transfer of old->new source information
in the transformation of forms.

In the mean time, I've got the symbols approach "working".  In
particular, I can byte compile the file from Roland Winkler's bug #9109,
and get the "free variable" warning message indicating the correct
source line (and, with a little more work to be done, the correct
column).  It is not quite ready to demonstrate, but quite near it.

Incidentally, why do we not print line and column numbers for warnings
in compile_defun?  It wouldn't be difficult.

>         Stefan

Alan Mackenzie (Nuremberg, Germany).

reply via email to

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