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

[Stefan Monnier]

>> > I timed a bootstrap, unoptimised GCC, with an extra tag check and
>> > storage to a global variable inserted into XFIXNUM.  (Currently there is
>> > no such check there).  The slowdown was around 1.3%
>
>> That accumulates for every data type, and it increases code size,
>> reduces cache hit rate...
>
> No, it applies mainly to FIXNUM, because XFIXNUM doesn't already check
> the Lisp_Type.  Other object types already perform this check, so while

I'm not sure why you say that.  XCONS/XSYMBOL don't perform the check
either (unless you compile with debug-checks, of course, but that's not
the important case).

> Yes, it may be a bad option, but possibly less bad than the other bad
> options we have.

There's indeed a pretty good set of bad options at hand.  Not sure which
one will suck less.

> cconv.el would need to be entirely rewritten if we stick to the hash
> table approach.  It wouldn't survive anything like unscathed even in an
> "extended Lisp Object" solution.

It's "only" the cconv-convert part of cconv.el that will need changes,
but yes, one way or another it will need to be changed to preserve the
location info.

> Maybe it would be possible to defer cconv.el processing till after macro
> expansion and byte-opt.el stuff.  Would this do any good?

It's already done after macro expansion (but before byte-opt).
I don't think it moving it would help.

> The only vague idea I have for saving this, and I don't like it one bit,
> is somehow to redefine \` (and possibly \,) in such a way that it would
> somehow copy the source position from the original list to the result.

Define "original list" ;-)

>> Same with your new scheme: everywhere where a "big cons-cell" is
>> transformed, by a macro you'll get a "small cons-cell".
>> That's a constant of all options, AFAICT.
> The "extended" symbols would survive.  That is a big plus.

Indeed symbols are usually preserved un-touched.

> I've been through these sort of thoughts.  That idea would be less
> effective than the "extended object", since it would only work with
> conses, but might be less disruptive.  But why should it only work with
> conses?

No particular reason at first.

> Why not with symbols, too?

Reproducing this idea for other types is not always that easy or useful:
- for pseudo-vectors the variable size aspect makes it harder to handle
  (tho not impossible).  OTOH we could probably use a bit in the header
  and thus avoid the need to place those extended objects in their
  own blocks.
- for symbols the extra info is "per symbol occurrence" rather than "per
  symbol", so we can't add this info directly to the symbol (i.e. the
  same reason the hash-table approach doesn't work for symbols).
  So we'd really want a completely separate object which then points to
  the underlying symbol object.  But yes, we could introduce a new
  symbol-occurrence object, along the lines you originally suggested but
  only for symbols (thus reducing the performance cost).


-- Stefan