[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: |
Tue, 6 Nov 2018 19:15:32 +0000 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
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).
- Thoughts on getting correct line numbers in the byte compiler's warning messages, Alan Mackenzie, 2018/11/01
- Re: Thoughts on getting correct line numbers in the byte compiler's warning messages, Stefan Monnier, 2018/11/06
- Re: Thoughts on getting correct line numbers in the byte compiler's warning messages, Alan Mackenzie, 2018/11/06
- Re: Thoughts on getting correct line numbers in the byte compiler's warning messages, Stefan Monnier, 2018/11/06
- Re: Thoughts on getting correct line numbers in the byte compiler's warning messages,
Alan Mackenzie <=
- Re: Thoughts on getting correct line numbers in the byte compiler's warning messages, Stefan Monnier, 2018/11/06
- Re: Thoughts on getting correct line numbers in the byte compiler's warning messages, Alan Mackenzie, 2018/11/07
- Re: Thoughts on getting correct line numbers in the byte compiler's warning messages, Stefan Monnier, 2018/11/07
- Re: Thoughts on getting correct line numbers in the byte compiler's warning messages, Alan Mackenzie, 2018/11/07
- Re: Thoughts on getting correct line numbers in the byte compiler's warning messages, Stefan Monnier, 2018/11/07
- Re: Thoughts on getting correct line numbers in the byte compiler's warning messages, Alan Mackenzie, 2018/11/07
- Re: Thoughts on getting correct line numbers in the byte compiler's warning messages, Stefan Monnier, 2018/11/07
- Re: Thoughts on getting correct line numbers in the byte compiler's warning messages, Alan Mackenzie, 2018/11/08
- Re: Thoughts on getting correct line numbers in the byte compiler's warning messages, Stefan Monnier, 2018/11/08
- Re: Thoughts on getting correct line numbers in the byte compiler's warning messages, Alan Mackenzie, 2018/11/08