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: Wed, 7 Nov 2018 12:35:10 +0000 Message-ID: <20181107123510.GA3966@ACM> 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; charset=us-ascii X-Trace: blaine.gmane.org 1541594062 8782 195.159.176.226 (7 Nov 2018 12:34:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 7 Nov 2018 12:34:22 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 07 13:34:18 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 1gKN2I-00027g-7l for ged-emacs-devel@m.gmane.org; Wed, 07 Nov 2018 13:34:18 +0100 Original-Received: from localhost ([::1]:47594 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gKN4O-0003US-HL for ged-emacs-devel@m.gmane.org; Wed, 07 Nov 2018 07:36:28 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36313) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gKN4G-0003UG-Qu for emacs-devel@gnu.org; Wed, 07 Nov 2018 07:36:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gKN4B-000580-5k for emacs-devel@gnu.org; Wed, 07 Nov 2018 07:36:19 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:52807 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gKN4A-00055z-Qn for emacs-devel@gnu.org; Wed, 07 Nov 2018 07:36:15 -0500 Original-Received: (qmail 55891 invoked by uid 3782); 7 Nov 2018 12:36:13 -0000 Original-Received: from acm.muc.de (p5B147AD4.dip0.t-ipconnect.de [91.20.122.212]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 07 Nov 2018 13:36:11 +0100 Original-Received: (qmail 4475 invoked by uid 1000); 7 Nov 2018 12:35:10 -0000 Content-Disposition: inline In-Reply-To: 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:231048 Archived-At: Hello, Stefan. On Tue, Nov 06, 2018 at 15:04:51 -0500, Stefan Monnier wrote: > >> > 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)? Looking at notes I made at the time, I amended a small portion of e.g. byte-optimize-body to make a new hash entry with the same value when a form was transformed. The slowdown on just the byte optimiser was around a factor of three. I think the comparison was with the byte-optimiser in the released version (without any hash tables). > > 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? I don't think I follow myself here. I was thinking that accessing a hash table element was slow, therefore keeping a table value current and pushing transformed forms onto it would be faster than creating a new hash table entry for these new forms. Looking at the code for hash tables, the access time can not be all that long. > > 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? For objects created by the reader, they can be looked up in the hash table. But your real question .... > 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? Either by making new entries in the table for transformed forms, or by noting byte-compile-containing-form and "sub-form number 2" and using read (or forward-sexp, even) on the source text to move forward to sub-form 2. > 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? That's the sort of thing, yes. > Stefan -- Alan Mackenzie (Nuremberg, Germany).