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: Tue, 6 Nov 2018 19:15:32 +0000 Message-ID: <20181106191532.GC4030@ACM> References: <20181101175953.GC4504@ACM> <20181105105302.GA10520@ACM> <20181106151143.GB4030@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1541531699 10010 195.159.176.226 (6 Nov 2018 19:14:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 6 Nov 2018 19:14:59 +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 Tue Nov 06 20:14:55 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 1gK6oM-0002Pq-Q8 for ged-emacs-devel@m.gmane.org; Tue, 06 Nov 2018 20:14:50 +0100 Original-Received: from localhost ([::1]:42694 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gK6qT-0000QD-1N for ged-emacs-devel@m.gmane.org; Tue, 06 Nov 2018 14:17:01 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46352) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gK6qI-0000Og-1r for emacs-devel@gnu.org; Tue, 06 Nov 2018 14:16:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gK6qD-0006FI-Ud for emacs-devel@gnu.org; Tue, 06 Nov 2018 14:16:49 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:60144 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gK6qD-0005hL-II for emacs-devel@gnu.org; Tue, 06 Nov 2018 14:16:45 -0500 Original-Received: (qmail 41657 invoked by uid 3782); 6 Nov 2018 19:16:27 -0000 Original-Received: from acm.muc.de (p5B14799F.dip0.t-ipconnect.de [91.20.121.159]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 06 Nov 2018 20:16:26 +0100 Original-Received: (qmail 10957 invoked by uid 1000); 6 Nov 2018 19:15:33 -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:231046 Archived-At: Hello again, Stefan. Now for something completely different. On Tue, Nov 06, 2018 at 11:29:41 -0500, Stefan Monnier wrote: [ .... ] > So in the long run it [Alan's idea for extended Lisp Objects] is a bad > option. I feel that intuitively, hence agree with you. It would be nice to have robust warning line numbers, though. In the rest of this post, I will no longer be discussing this scheme. > > 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. 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. Finding a form in that table for a warning message would be much slower, but that shouldn't matter. [ .... ] > > Also, there's no convenient key for recording the hash of an > > occurence of a symbol (such as `if'). > Ah, right, I keep forgetting this detail. Yes, that's a major downer. Here's my latest idea: we maintain byte-compile-containing-forms as a stack of containing forms. Each time we're manipulating a list of forms, we increment a counter N with each form. That form is often a symbol. 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. [ .... ] > How 'bout we don't try to add location to all objects, but only to some > specific objects? E.g. only cons-cells? Yes, and vectors too. Integers, symbols, strings, and floats, no. [ .... ] > Stefan -- Alan Mackenzie (Nuremberg, Germany).