emacs-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]