From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Thoughts on getting correct line numbers in the byte compiler's warning messages Date: Sun, 11 Nov 2018 20:12:14 +0000 Message-ID: <20181111201214.GA8219@ACM> References: <20181107170036.GA4934@ACM> <20181107184708.GB4934@ACM> <20181108140843.GB5041@ACM> <20181108221311.GD5041@ACM> <20181111125945.GA6487@ACM> <83k1lja9w6.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1541967116 12311 195.159.176.226 (11 Nov 2018 20:11:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 11 Nov 2018 20:11:56 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: michael_heerdegen@web.de, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 11 21:11:51 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gLw5H-00036G-5n for ged-emacs-devel@m.gmane.org; Sun, 11 Nov 2018 21:11:51 +0100 Original-Received: from localhost ([::1]:43519 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gLw7N-0000Ma-Az for ged-emacs-devel@m.gmane.org; Sun, 11 Nov 2018 15:14:01 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42705) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gLw7F-0000MF-CT for emacs-devel@gnu.org; Sun, 11 Nov 2018 15:13:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gLw7C-0005JO-8M for emacs-devel@gnu.org; Sun, 11 Nov 2018 15:13:53 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:25716 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gLw7B-0005IN-Ri for emacs-devel@gnu.org; Sun, 11 Nov 2018 15:13:50 -0500 Original-Received: (qmail 86752 invoked by uid 3782); 11 Nov 2018 20:13:48 -0000 Original-Received: from acm.muc.de (p5B14619F.dip0.t-ipconnect.de [91.20.97.159]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 11 Nov 2018 21:13:46 +0100 Original-Received: (qmail 12453 invoked by uid 1000); 11 Nov 2018 20:12:14 -0000 Content-Disposition: inline In-Reply-To: <83k1lja9w6.fsf@gnu.org> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:231075 Archived-At: 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 > > Cc: Michael Heerdegen , 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).