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

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Wed, Nov 07, 2018 at 14:12:41 -0500, Stefan Monnier wrote:
> >> It's "only" the cconv-convert part of cconv.el that will need changes,
> >> but yes, one way or another it will need to be changed to preserve the
> >> location info.
> > OK.  But it's still a challenging job.

> I wouldn't call it challenging: the changes are orthogonal to the actual
> working of cconv, so it will likely make the code messier but
> conceptually there's no significant difficulty.  I'm familiar with the
> code and will be happy to help.

Thanks!  By the way, am I right in thinking that pcase does its
comparisons using equal?

[ .... ]

> >>   So we'd really want a completely separate object which then points to
> >>   the underlying symbol object.  But yes, we could introduce a new
> >>   symbol-occurrence object, along the lines you originally suggested but
> >>   only for symbols (thus reducing the performance cost).
> > :-)  This could be a pseudovector, leaving Lisp_Type 1 free for more
> > worthy uses.  You're suggesting a mix of approaches.  This might be more
> > complicated, but possibly the least pessimal.

> One possible approach is to introduce such a symbol-occurrence hack
> [if this word sounds like a criticism, it's because it is] and nothing
> else (i.e. not a "mix" of approaches).

This sounds like a good idea.

> To the extent that symbols aren't touched during the various phases, the
> corresponding info should trivially be preserved.  The current hack we
> use is also limited to tracking symbol locations, so it should never be
> worse than what we already have.

One thing we'd need to watch out for is using equal, not eq, when we
compare symbols.  (eq 'foo #<symbol foo with position 73>) will surely
be nil, but (equal ....) would be t.  Same with member and memq.

We'd also need to make sure that the reader's enabling flag for creating
these extended symbols is bound to nil whenever we suspend the byte
compiler to do something else (edebug, for example).

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).