From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Thoughts on getting correct line numbers in the byte compiler's warning messages Date: Tue, 06 Nov 2018 15:04:51 -0500 Message-ID: References: <20181101175953.GC4504@ACM> <20181105105302.GA10520@ACM> <20181106151143.GB4030@ACM> <20181106191532.GC4030@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1541534692 7902 195.159.176.226 (6 Nov 2018 20:04:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 6 Nov 2018 20:04:52 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 06 21:04:48 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 1gK7ah-0001vZ-Sq for ged-emacs-devel@m.gmane.org; Tue, 06 Nov 2018 21:04:47 +0100 Original-Received: from localhost ([::1]:42799 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gK7co-0003Tf-3x for ged-emacs-devel@m.gmane.org; Tue, 06 Nov 2018 15:06:58 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40331) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gK7by-0003NL-K0 for emacs-devel@gnu.org; Tue, 06 Nov 2018 15:06:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gK7b5-0006BN-3l for emacs-devel@gnu.org; Tue, 06 Nov 2018 15:05:15 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:36344) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gK7b4-0005MS-Ll for emacs-devel@gnu.org; Tue, 06 Nov 2018 15:05:10 -0500 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id wA6K4pi8026224; Tue, 6 Nov 2018 15:04:51 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 882436A477; Tue, 6 Nov 2018 15:04:51 -0500 (EST) In-Reply-To: <20181106191532.GC4030@ACM> (Alan Mackenzie's message of "Tue, 6 Nov 2018 19:15:32 +0000") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6412=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6412> : inlines <6955> : streams <1803507> : uri <2745315> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:231047 Archived-At: >> > Many of the original forms produced by the reader survive these >> > transformations. >> Yeah, that's why I thought of using a hash-table. > What I tried before (about two years ago) was having each > reader-produced form as a key, and the source position as a value. Each > time the source was transformed, the new form became a new key, and the > value stayed the same. > > I vaguely remember this being slow. Which part do you remember being slow (e.g. just performing a `read` that returns a sexp and fills that table along the way)? > Maybe it would be better the other way around. The source position > would be the key, and the value would be a list of (equivalent) forms. > Building this table would be faster. I don't follow you: why would this be faster? > Finding a form in that table for a warning message would be much > slower, but that shouldn't matter. It could matter, but yeah, let's not worry about that for now. > In byte-compile-warn, if we can't find the current form in the above > table, we search for the containing form, get its source offset, put > point there and read the next N forms, moving forward in the source text > to the position we need. That this might be slow (I don't really think > it would be) is again unimportant. I lost you here as well: how is the location data propagated from the reader to the byte-compiler's phase that ends up running byte-compile-warn? I mean, how is the location info preserved while going through macro-expansion, closure-conversion, and byte-optimize-form? Or are most objects left untouched in practice? I guess we could limit the info (e.g. stored in a hash-table) to map "first cons-cell in a list" to its location info, and then change macroexp.el, cconv.el, and friends to preserve this info as much as possible (we may even come up with a `with-location-data` macro that encapsulates most of the work so the changes are easy to apply). Is that what you're thinking of? Stefan