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

[Alan Mackenzie <acm@muc.de>]

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