[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: |
Stefan Monnier |
Subject: |
Re: Thoughts on getting correct line numbers in the byte compiler's warning messages |
Date: |
Tue, 06 Nov 2018 15:04:51 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
>> > 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.
Which part do you remember being slow (e.g. just performing a `read`
that returns a sexp and fills that table along the way)?
> 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.
I don't follow you: why would this be faster?
> Finding a form in that table for a warning message would be much
> slower, but that shouldn't matter.
It could matter, but yeah, let's not worry about that for now.
> 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.
I lost you here as well: how is the location data propagated from the
reader to the byte-compiler's phase that ends up running
byte-compile-warn? I mean, how is the location info
preserved while going through macro-expansion, closure-conversion,
and byte-optimize-form? Or are most objects left untouched in practice?
I guess we could limit the info (e.g. stored in a hash-table) to map
"first cons-cell in a list" to its location info, and then change
macroexp.el, cconv.el, and friends to preserve this info as much as
possible (we may even come up with a `with-location-data` macro that
encapsulates most of the work so the changes are easy to apply).
Is that what you're thinking of?
Stefan
- Re: Thoughts on getting correct line numbers in the byte compiler's warning messages, (continued)
- 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, 2018/11/06
- Re: Thoughts on getting correct line numbers in the byte compiler's warning messages,
Stefan Monnier <=
- 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
- Re: Thoughts on getting correct line numbers in the byte compiler's warning messages, Alan Mackenzie, 2018/11/11