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

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

> Maybe not.  I was thinking that if it was deferred until after byte-opt,
> "all" the warning messages would have the right position info.  But
> cconv.el calls byte-compile-warn, too.

Some/many(most?) of the warnings come from bytecomp itself which
inevitably happens after all of the above anyway.

> As I say, I don't like the idea, but it might be the best we can come up
> with, and still have a readable and maintainable cconv.el.

Yes, we'd probably use a hack along these lines to try and limit the
impact of the change.

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

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.


        Stefan