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: Thu, 8 Nov 2018 11:07:23 +0000 Message-ID: <20181108110723.GA5041@ACM> References: <20181101175953.GC4504@ACM> <87efbwuqek.fsf@web.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1541675214 4846 195.159.176.226 (8 Nov 2018 11:06:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 8 Nov 2018 11:06:54 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: emacs-devel@gnu.org To: Michael Heerdegen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 08 12:06:50 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 1gKi9B-00018l-Gc for ged-emacs-devel@m.gmane.org; Thu, 08 Nov 2018 12:06:49 +0100 Original-Received: from localhost ([::1]:55915 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gKiBH-0006hF-7i for ged-emacs-devel@m.gmane.org; Thu, 08 Nov 2018 06:08:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53793) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gKiB2-0006Qq-RI for emacs-devel@gnu.org; Thu, 08 Nov 2018 06:08:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gKiAx-0002Xi-Rt for emacs-devel@gnu.org; Thu, 08 Nov 2018 06:08:44 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:35590 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gKiAw-0002SB-Ha for emacs-devel@gnu.org; Thu, 08 Nov 2018 06:08:39 -0500 Original-Received: (qmail 4768 invoked by uid 3782); 8 Nov 2018 11:08:32 -0000 Original-Received: from acm.muc.de (p5B147A20.dip0.t-ipconnect.de [91.20.122.32]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 08 Nov 2018 12:08:31 +0100 Original-Received: (qmail 5115 invoked by uid 1000); 8 Nov 2018 11:07:23 -0000 Content-Disposition: inline In-Reply-To: <87efbwuqek.fsf@web.de> 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:231055 Archived-At: Hello, Michael. On Thu, Nov 08, 2018 at 05:47:15 +0100, Michael Heerdegen wrote: > Alan Mackenzie writes: > > The third idea is to amend the reader so that whereas it now produces a > > form, in a byte compiler special mode, it would produce the cons (form . > > offset). So, for example, the text "(not a)" currently gets read into > > the form (not . (a . nil)). The amended reader would produce (((not . 1) > > . ((a . 5) . (nil . 6))) . 0) (where 0, 1, 5, and 6 are the textual > > offsets of the elements coded). > BTW, an amended version of `read' might be beneficial for other stuff, > too. When I designed el-search, I wanted something like that. As it turned out, the above scheme would not be useful, because a macro could not manipulate such a form. The ideas are currently in flux, in a discussion between Stefan and me, and we've come up with several ideas, all bad. ;-) We're currently trying to select the least bad idea. > I'm not sure which kind of position info data I would like to have. I > think it would be good to have additionally starting positions of > conses, for example. I came up with a way of doing this, using the spare value of Lisp_Type in a Lisp_Object to indicate an indirection to a structure of two Lisp_Objects. The first would be the actual object, the second would be position information. The trouble with this is it would slow down Emacs performance significantly (possibly as much as ~10%). It would also be difficult to implement, since at each transformation of the form being compiled, position information would need to be copied to the new version of form. Stefan's latest suggestion is to use the above approach just on symbol occurrences. (Sorry!). These are preserved through transformations much more than cons cells are. Also, the existing approach in the compiler only tracks symbol occurrences, so we will not lose anything by tracking only symbols, but more accurately. Even so, this will be a lot of work. If some code wants to get the starting position of a cons, the source code will surely be in a buffer somewhere. As long as there is a symbol in the cons (i.e., we don't have ()), surely the cons position can be found from the contained symbol, together with backward-up-list in the source buffer. Or something like that. > Michael. -- Alan Mackenzie (Nuremberg, Germany).