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: Mon, 5 Nov 2018 16:51:37 +0000 Message-ID: <20181105165137.GB10520@ACM> References: <20181101175953.GC4504@ACM> <20181105105302.GA10520@ACM> <83y3a7cya8.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 1541437901 12833 195.159.176.226 (5 Nov 2018 17:11:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 5 Nov 2018 17:11:41 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: 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 Mon Nov 05 18:11:37 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 1gJiPU-00038l-I0 for ged-emacs-devel@m.gmane.org; Mon, 05 Nov 2018 18:11:32 +0100 Original-Received: from localhost ([::1]:36411 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gJiRa-0005wW-PT for ged-emacs-devel@m.gmane.org; Mon, 05 Nov 2018 12:13:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56426) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gJi7F-0007sQ-SH for emacs-devel@gnu.org; Mon, 05 Nov 2018 11:52:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gJi75-00043J-Co for emacs-devel@gnu.org; Mon, 05 Nov 2018 11:52:34 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:62984 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gJi6w-0003zh-LC for emacs-devel@gnu.org; Mon, 05 Nov 2018 11:52:24 -0500 Original-Received: (qmail 27965 invoked by uid 3782); 5 Nov 2018 16:52:17 -0000 Original-Received: from acm.muc.de (p5B147DFB.dip0.t-ipconnect.de [91.20.125.251]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 05 Nov 2018 17:52:16 +0100 Original-Received: (qmail 12949 invoked by uid 1000); 5 Nov 2018 16:51:37 -0000 Content-Disposition: inline In-Reply-To: <83y3a7cya8.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:231030 Archived-At: Hello, Eli. On Mon, Nov 05, 2018 at 17:57:35 +0200, Eli Zaretskii wrote: > > Date: Mon, 5 Nov 2018 10:53:02 +0000 > > From: Alan Mackenzie > > Cc: emacs-devel@gnu.org > > The reader would produce, in place of the Lisp_Objects it currently > > does, an object with Lisp_Type 1 (which is currently unused). The rest > > of the object would be an address pointing at two Lisp_Objects, one > > being the "real" read object, the other being a source position. > Sounds gross to me. What is done at the moment is no less gross. Just to clarify, the above acton of read would only be done when in byte compilation, a bit like how the current list of source symbols is also only for when in compilation. I've spend many hours at my PC, trying to figure out a neat way of solving this problem. The above is the best I've been able to come up with, so far. Why do you think the idea is gross, given the difficulty of the underlying problem? The idea should work with only moderate amendment of the byte-compiler/macro routines, and virtually no change outside of that, bar amending the reader and the lowest level functions like `cons' and `car'. > Did you consider using mint_ptr objects instead? That'd be still be > gross, but at least we won't introduce another type of Lisp_Object. The using up of the last available object type is a severe disadvantage, yes. I wasn't aware of mint_ptrs until you just mentioned them. I'll need to read up on them to get the hang of what they're about. > Also, what about keeping the source position in some other way, like a > property of some symbol? Difficult. Essentially, these source positions are properties of Lisp_Objects, such as conses, not of symbols. A typical symbol is used several or many times in a compilation unit. Some means has to be found of attaching properties (in this case, source positions), to arbitrary Lisp_Objects. It's gradually become clear to me that what I proposed this morning is a special case of attaching a property list to an arbitrary object. Maybe an actual property list, being more general, would be a better idea. Alternatively, it may be possible to use a vector or pseudovector type rather than using Lisp_Type 1 to implement basically the same idea. This would be slower at run time, however, possibly not significantly. -- Alan Mackenzie (Nuremberg, Germany).