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

[Alan Mackenzie <acm@muc.de>]

Hello again, Stefan.

Now for something completely different.

On Tue, Nov 06, 2018 at 11:29:41 -0500, Stefan Monnier wrote:

[ .... ]

> So in the long run it [Alan's idea for extended Lisp Objects] is a bad
> option.

I feel that intuitively, hence agree with you.  It would be nice to have
robust warning line numbers, though.

In the rest of this post, I will no longer be discussing this scheme.

> > Many of the original forms produced by the reader survive these
> > transformations.

> Yeah, that's why I thought of using a hash-table.

What I tried before (about two years ago) was having each
reader-produced form as a key, and the source position as a value.  Each
time the source was transformed, the new form became a new key, and the
value stayed the same.

I vaguely remember this being slow.

Maybe it would be better the other way around.  The source position
would be the key, and the value would be a list of (equivalent) forms.
Building this table would be faster.  Finding a form in that table for a
warning message would be much slower, but that shouldn't matter.

[ .... ]

> > Also, there's no convenient key for recording the hash of an
> > occurence of a symbol (such as `if').

> Ah, right, I keep forgetting this detail.  Yes, that's a major downer.

Here's my latest idea: we maintain byte-compile-containing-forms as a
stack of containing forms.  Each time we're manipulating a list of
forms, we increment a counter N with each form.  That form is often a
symbol.

In byte-compile-warn, if we can't find the current form in the above
table, we search for the containing form, get its source offset, put
point there and read the next N forms, moving forward in the source text
to the position we need.  That this might be slow (I don't really think
it would be) is again unimportant.

[ .... ]

> How 'bout we don't try to add location to all objects, but only to some
> specific objects?  E.g. only cons-cells?

Yes, and vectors too.  Integers, symbols, strings, and floats, no.

[ .... ]

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).