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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

Thanks for the reply and comments.

On Sun, Nov 11, 2018 at 17:53:13 +0200, Eli Zaretskii wrote:
> > Date: Sun, 11 Nov 2018 12:59:45 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: Michael Heerdegen <michael_heerdegen@web.de>, emacs-devel@gnu.org
> > 
> > I've now got this working, and created the new, optimistically named,
> > branch /scratch/accurate-warning-pos.

> Thanks.

>   +/* Return a new located symbol with the specified SYMBOL and LOCATION. */
>   +Lisp_Object
>   +build_located_symbol (Lisp_Object symbol, Lisp_Object location)
>   +{

> I'd prefer something like symbol_with_pos instead, and accordingly in
> other related symbol names.

Yes, I'll do that.  "Located Symbol" is too much of a mouthfull.
Thinking up names for new things isn't my strong point.

>   +DEFUN ("only-symbol-p", Fonly_symbol_p, Sonly_symbol_p, 1, 1, 0,
>   +       doc: /* Return t if OBJECT is a symbol, but not a located symbol.  */
>   +       attributes: const)
>   +  (Lisp_Object object)

> symbol-bare-p?

How about bare-symbol-p?  symbol-bare-p has the connotations "we have a
symbol; is it bare?" rather than "have we a bare symbol?".

>   +  DEFVAR_LISP ("located-symbols-enabled", Vlocated_symbols_enabled,
>   +               doc: /* Non-nil when "located symbols" can be used in place of symbols.

> What is the rationale for this variable?

In the new lisp_h_SYMBOLP, we have

#define lisp_h_SYMBOLP(x) ((lisp_h_ONLY_SYMBOL_P (x) || \
                            (Vlocated_symbols_enabled && (lisp_h_LOCATED_SYMBOL_P (x)))))

The Vlocated_symbols_enabled should efficiently prevent a potentially
slow lisp_h_LOCATED_SYMBOL_P from being executed in the overwhelmingly
normal case that we don't have "symbols with pos".  It is a simple test
against binary zero, and the word should be permanently in cache.

Another, slightly more honest, answer is that when it wasn't there, my
Emacs build crashed with a segfault whilst loading .el files.  I didn't
get a core dump for this segfault.  Could you please tell me (or point
me in the right direction of documentation) how I configure my GNU/Linux
to generate core dumps.  I think my kernel's set up correctly, but I
don't see the dumps.

>   diff --git a/src/lisp.h b/src/lisp.h
>   index eb67626..b4fc6f2 100644
>   --- a/src/lisp.h
>   +++ b/src/lisp.h
>   @@ -323,6 +323,64 @@ typedef union Lisp_X *Lisp_Word;
>    typedef EMACS_INT Lisp_Word;
>    #endif

>   +/* A Lisp_Object is a tagged pointer or integer.  Ordinarily it is a
>   +   Lisp_Word.  However, if CHECK_LISP_OBJECT_TYPE, it is a wrapper
>   +   around Lisp_Word, to help catch thinkos like 'Lisp_Object x = 0;'.
>   +
>   +   LISP_INITIALLY (W) initializes a Lisp object with a tagged value
>   +   that is a Lisp_Word W.  It can be used in a static initializer.  */

> Looks like you moved a large chunk of lisp.h to a different place in
> the file.  Any reasons for that?

I did this to get things to compile.  lisp.h is intricate and
complicated.  But it turned out I'd moved far more than I needed.  With
the benefit of a night's sleep, I've restored most of the damage.  All
that's been moved now is some inline functions (SYMBOLP, XSYMBOL, ....,
CHECK_SYMBOL) from before More_Lisp_Bits to after it, since they now
depend on More_Lisp_Bits.

>   +/* FIXME!!! 2018-11-09.  Consider using lisp_h_PSEUDOVECTOR here. */

> What is this FIXME about?

It was a note to self about whether just to invoke the (new) macro
lisp_h_PSEUDOVECTOR, rather than repeating the logic in the inline
function.  Sorry it escaped into the wild.  The answer is, I MUST invoke
the macro, to avoid duplication of functionality.

> This needs support in src/.gdbinit and documentation.

Yes!  I think .gdbinit will be relatively straightforward.  How much to
put into the docs (the elisp manual?) is more difficult to decide.
Although primariliy for the byte compiler, Michael Heerdegen has already
said he's got other uses for it.

> Thanks again for working in this.

-- 
Alan Mackenzie (Nuremberg, Germany).