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, 15 Nov 2018 16:32:00 +0000 Message-ID: <20181115163200.GA7216@ACM> References: <20181107170036.GA4934@ACM> <20181107184708.GB4934@ACM> <20181108140843.GB5041@ACM> <20181112154448.GB4459@ACM> <20181112213513.GD4459@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1542299599 16389 195.159.176.226 (15 Nov 2018 16:33:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Nov 2018 16:33:19 +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 15 17:33:15 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 1gNKZv-00049N-3y for ged-emacs-devel@m.gmane.org; Thu, 15 Nov 2018 17:33:15 +0100 Original-Received: from localhost ([::1]:39736 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gNKc1-0001hM-Ig for ged-emacs-devel@m.gmane.org; Thu, 15 Nov 2018 11:35:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39740) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gNKat-0001h8-E3 for emacs-devel@gnu.org; Thu, 15 Nov 2018 11:34:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gNKam-0001L1-Kz for emacs-devel@gnu.org; Thu, 15 Nov 2018 11:34:15 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:64455 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gNKam-0001Jg-AX for emacs-devel@gnu.org; Thu, 15 Nov 2018 11:34:08 -0500 Original-Received: (qmail 49153 invoked by uid 3782); 15 Nov 2018 16:34:06 -0000 Original-Received: from acm.muc.de (p5B147559.dip0.t-ipconnect.de [91.20.117.89]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 15 Nov 2018 17:34:05 +0100 Original-Received: (qmail 7271 invoked by uid 1000); 15 Nov 2018 16:32:00 -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:231169 Archived-At: Hello, Stefan. On Wed, Nov 14, 2018 at 08:34:28 -0500, Stefan Monnier wrote: > >> Changing `eq` would better be avoided, > > I agree, but don't see how we can avoid it. > Oh... you mean when someone else's macro does for example > (defmacro ... > (if (eq x 'foo) > `(...) > `(...))) Yes. > ...hmm... yes, this is getting really ugly. > 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. > It will require special code in alloc.c to keep the special > representation of normal cons-cells, and special extra code to propagate > the location information in macroexp.el, cconv.el, byte-opt.el, > bytecomp.el but the impact should be much more localized (and at places > where normal compilers also have to do this kind of work). In branch scratch/accurate-warning-pos I have hacked up (but not committed) an EQ which works with the (new as of a few days ago) PVEC structure for symbols with position. I am now able to byte-compile a .el file with symbols-with-pos-enabled bound to non-nil, having sorted out the problem that was earlier causing segfaults (probably). This version of Emacs is slower by ~8%, but this is tempered by the EQ implementation being extremely naive without any optimsation. Also some existing optimsation (e.g. #define EQ) has been commented out to enable the files to compile. I don't understand the relationship between "#define EQ" and the inline function EQ at all well. Optimsation will be surely be possible. > Stefan -- Alan Mackenzie (Nuremberg, Germany).