[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: |
Thu, 15 Nov 2018 16:32:00 +0000 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
Hello, Stefan.
On Wed, Nov 14, 2018 at 08:34:28 -0500, Stefan Monnier wrote:
> >> Changing `eq` would better be avoided,
> > I agree, but don't see how we can avoid it.
> Oh... you mean when someone else's macro does for example
> (defmacro ...
> (if (eq x 'foo)
> `(...)
> `(...)))
Yes.
> ...hmm... yes, this is getting really ugly.
> Maybe the "big cons-cells" approach is not that bad after all, since it
> doesn't try to introduce new objects which are "equal but not": it just
> introduces a subtype of cons-cells and that's that, so it's semantically
> much simpler/cleaner.
I'm not sure about that. We'd still have to modify EQ to cope with the
new structure no matter how we do it.
> It will require special code in alloc.c to keep the special
> representation of normal cons-cells, and special extra code to propagate
> the location information in macroexp.el, cconv.el, byte-opt.el,
> bytecomp.el but the impact should be much more localized (and at places
> where normal compilers also have to do this kind of work).
In branch scratch/accurate-warning-pos I have hacked up (but not
committed) an EQ which works with the (new as of a few days ago) PVEC
structure for symbols with position. I am now able to byte-compile a
.el file with symbols-with-pos-enabled bound to non-nil, having sorted
out the problem that was earlier causing segfaults (probably).
This version of Emacs is slower by ~8%, but this is tempered by the EQ
implementation being extremely naive without any optimsation. Also some
existing optimsation (e.g. #define EQ) has been commented out to enable the
files to compile. I don't understand the relationship between "#define
EQ" and the inline function EQ at all well. Optimsation will be surely
be possible.
> Stefan
--
Alan Mackenzie (Nuremberg, Germany).
- 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, Eli Zaretskii, 2018/11/12
- Re: Thoughts on getting correct line numbers in the byte compiler's warning messages, Alan Mackenzie, 2018/11/12
- Re: Thoughts on getting correct line numbers in the byte compiler's warning messages, Alan Mackenzie, 2018/11/12
- Re: Thoughts on getting correct line numbers in the byte compiler's warning messages, Stefan Monnier, 2018/11/12
- Re: Thoughts on getting correct line numbers in the byte compiler's warning messages, Alan Mackenzie, 2018/11/12
- Re: Thoughts on getting correct line numbers in the byte compiler's warning messages, Stefan Monnier, 2018/11/14
- 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/15
- Re: Thoughts on getting correct line numbers in the byte compiler's warning messages, Alan Mackenzie, 2018/11/16
Re: Thoughts on getting correct line numbers in the byte compiler's warning messages, Michael Heerdegen, 2018/11/07
Re: Thoughts on getting correct line numbers in the byte compiler's warning messages, Stefan Monnier, 2018/11/08