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 14:08:43 +0000 Message-ID: <20181108140843.GB5041@ACM> References: <20181101175953.GC4504@ACM> <20181105105302.GA10520@ACM> <20181106151143.GB4030@ACM> <20181107170036.GA4934@ACM> <20181107184708.GB4934@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1541686162 25809 195.159.176.226 (8 Nov 2018 14:09:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 8 Nov 2018 14:09: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 Thu Nov 08 15:09: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 1gKkzl-0006Xx-Hv for ged-emacs-devel@m.gmane.org; Thu, 08 Nov 2018 15:09:17 +0100 Original-Received: from localhost ([::1]:57005 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gKl1s-0002sk-1U for ged-emacs-devel@m.gmane.org; Thu, 08 Nov 2018 09:11:28 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47842) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gKl0Q-0001sW-AE for emacs-devel@gnu.org; Thu, 08 Nov 2018 09:09:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gKl0M-0004Zp-Ti for emacs-devel@gnu.org; Thu, 08 Nov 2018 09:09:58 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:12679 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gKl0M-0004YN-Ic for emacs-devel@gnu.org; Thu, 08 Nov 2018 09:09:54 -0500 Original-Received: (qmail 72189 invoked by uid 3782); 8 Nov 2018 14:09:52 -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 15:09:51 +0100 Original-Received: (qmail 5663 invoked by uid 1000); 8 Nov 2018 14:08:43 -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:231057 Archived-At: Hello, Stefan. On Wed, Nov 07, 2018 at 14:12:41 -0500, Stefan Monnier wrote: > >> It's "only" the cconv-convert part of cconv.el that will need changes, > >> but yes, one way or another it will need to be changed to preserve the > >> location info. > > OK. But it's still a challenging job. > I wouldn't call it challenging: the changes are orthogonal to the actual > working of cconv, so it will likely make the code messier but > conceptually there's no significant difficulty. I'm familiar with the > code and will be happy to help. Thanks! By the way, am I right in thinking that pcase does its comparisons using equal? [ .... ] > >> So we'd really want a completely separate object which then points to > >> the underlying symbol object. But yes, we could introduce a new > >> symbol-occurrence object, along the lines you originally suggested but > >> only for symbols (thus reducing the performance cost). > > :-) This could be a pseudovector, leaving Lisp_Type 1 free for more > > worthy uses. You're suggesting a mix of approaches. This might be more > > complicated, but possibly the least pessimal. > One possible approach is to introduce such a symbol-occurrence hack > [if this word sounds like a criticism, it's because it is] and nothing > else (i.e. not a "mix" of approaches). This sounds like a good idea. > To the extent that symbols aren't touched during the various phases, the > corresponding info should trivially be preserved. The current hack we > use is also limited to tracking symbol locations, so it should never be > worse than what we already have. One thing we'd need to watch out for is using equal, not eq, when we compare symbols. (eq 'foo #) will surely be nil, but (equal ....) would be t. Same with member and memq. We'd also need to make sure that the reader's enabling flag for creating these extended symbols is bound to nil whenever we suspend the byte compiler to do something else (edebug, for example). > Stefan -- Alan Mackenzie (Nuremberg, Germany).