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: Fri, 16 Nov 2018 14:14:45 +0000 Message-ID: <20181116141445.GA7958@ACM> References: <20181107184708.GB4934@ACM> <20181108140843.GB5041@ACM> <20181112154448.GB4459@ACM> <20181112213513.GD4459@ACM> <20181115163200.GA7216@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1542377769 23969 195.159.176.226 (16 Nov 2018 14:16:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Nov 2018 14:16:09 +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 Fri Nov 16 15:16:05 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 1gNeuf-00063R-Jq for ged-emacs-devel@m.gmane.org; Fri, 16 Nov 2018 15:16:01 +0100 Original-Received: from localhost ([::1]:45041 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gNewl-0008N4-Uh for ged-emacs-devel@m.gmane.org; Fri, 16 Nov 2018 09:18:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55653) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gNevf-0008M3-4e for emacs-devel@gnu.org; Fri, 16 Nov 2018 09:17:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gNevc-0006Mh-2R for emacs-devel@gnu.org; Fri, 16 Nov 2018 09:17:03 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:47352 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gNevb-0006Lf-Sk for emacs-devel@gnu.org; Fri, 16 Nov 2018 09:17:00 -0500 Original-Received: (qmail 18345 invoked by uid 3782); 16 Nov 2018 14:16:58 -0000 Original-Received: from acm.muc.de (p5B147676.dip0.t-ipconnect.de [91.20.118.118]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 16 Nov 2018 15:16:57 +0100 Original-Received: (qmail 7999 invoked by uid 1000); 16 Nov 2018 14:14:45 -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:231185 Archived-At: Hello, Stefan. On Thu, Nov 15, 2018 at 13:01:49 -0500, Stefan Monnier wrote: > >> Maybe the "big cons-cells" approach is not that bad after all, since it > >> doesn't try to introduce new objects which are "equal but not": it just > >> introduces a subtype of cons-cells and that's that, so it's semantically > >> much simpler/cleaner. > > I'm not sure about that. We'd still have to modify EQ to cope with the > > new structure no matter how we do it. > No need to modify EQ for the big-cons cells: a big-cons-cell would be > a normal cons-cell just with more fields added at its end. It's not > a "location + pointer to the real object" like we need to do for > symbols, so EQ will do the expected thing on it. Sorry, yes. We'd need some way of distinguishing between the two types of cons cell (which I think you already dealt with some while ago) and we'd need to do an awful lot of transfer of old->new source information in the transformation of forms. In the mean time, I've got the symbols approach "working". In particular, I can byte compile the file from Roland Winkler's bug #9109, and get the "free variable" warning message indicating the correct source line (and, with a little more work to be done, the correct column). It is not quite ready to demonstrate, but quite near it. Incidentally, why do we not print line and column numbers for warnings in compile_defun? It wouldn't be difficult. > Stefan -- Alan Mackenzie (Nuremberg, Germany).