From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Thoughts on getting correct line numbers in the byte compiler's warning messages Date: Wed, 07 Nov 2018 14:12:41 -0500 Message-ID: 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 X-Trace: blaine.gmane.org 1541617856 29067 195.159.176.226 (7 Nov 2018 19:10:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 7 Nov 2018 19:10:56 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 07 20:10:52 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 1gKTE3-0007SY-NL for ged-emacs-devel@m.gmane.org; Wed, 07 Nov 2018 20:10:51 +0100 Original-Received: from localhost ([::1]:50360 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gKTGA-0000op-0z for ged-emacs-devel@m.gmane.org; Wed, 07 Nov 2018 14:13:02 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54243) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gKTG3-0000oZ-Kc for emacs-devel@gnu.org; Wed, 07 Nov 2018 14:12:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gKTG0-0000gw-PX for emacs-devel@gnu.org; Wed, 07 Nov 2018 14:12:55 -0500 Original-Received: from [195.159.176.226] (port=49165 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gKTG0-0000ft-I3 for emacs-devel@gnu.org; Wed, 07 Nov 2018 14:12:52 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1gKTDq-0007Fw-Oy for emacs-devel@gnu.org; Wed, 07 Nov 2018 20:10:38 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 42 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:bHERg67iWB//TiUwY+eWoVlIrFo= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 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:231053 Archived-At: >> 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. > Maybe not. I was thinking that if it was deferred until after byte-opt, > "all" the warning messages would have the right position info. But > cconv.el calls byte-compile-warn, too. Some/many(most?) of the warnings come from bytecomp itself which inevitably happens after all of the above anyway. > As I say, I don't like the idea, but it might be the best we can come up > with, and still have a readable and maintainable cconv.el. Yes, we'd probably use a hack along these lines to try and limit the impact of the change. >> 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). 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. Stefan