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: Getting the correct line/column numbers on byte compilation error/warning messages Date: Mon, 17 Jul 2017 16:27:43 -0400 Message-ID: References: <20170716134429.GA3013@acm> <20170717195654.GB3647@acm> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1500323315 15790 195.159.176.226 (17 Jul 2017 20:28:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 17 Jul 2017 20:28:35 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 17 22:28:31 2017 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 1dXCd3-0003hC-N6 for ged-emacs-devel@m.gmane.org; Mon, 17 Jul 2017 22:28:29 +0200 Original-Received: from localhost ([::1]:52436 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dXCd7-0002ZF-9z for ged-emacs-devel@m.gmane.org; Mon, 17 Jul 2017 16:28:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34442) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dXCcS-0002YE-6O for emacs-devel@gnu.org; Mon, 17 Jul 2017 16:27:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dXCcO-0000jO-M0 for emacs-devel@gnu.org; Mon, 17 Jul 2017 16:27:52 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:58251) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dXCcO-0000j4-Fj for emacs-devel@gnu.org; Mon, 17 Jul 2017 16:27:48 -0400 Original-Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id v6HKRiSQ021788; Mon, 17 Jul 2017 16:27:44 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 069D7660CC; Mon, 17 Jul 2017 16:27:44 -0400 (EDT) In-Reply-To: <20170717195654.GB3647@acm> (Alan Mackenzie's message of "Mon, 17 Jul 2017 19:56:54 +0000") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6073=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6073> : inlines <5978> : streams <1754621> : uri <2464833> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:216799 Archived-At: >> Stefan "who'd actually prefer a =ABreal=BB solution rather than >> another hack, but beggars can't be choosers" > I've been thinking about this for nearly a year, and I can't conceive of > a "real" solution which doesn't involve redesigning the byte compiler > from scratch (or even one which does). AFAIK redesign is not needed (in the sense that the code structure doesn't need to be changed), but a lot of code would need to be touched, yes. > Lisp source code doesn't seem to lend itself to keeping track of > source positions as the forms are manipulated, taken apart, and put > together again. All compilers for all languages do that "take-apart-and-put-together" over and over again. The only difference is the Lisp macros which are defined to operate on a form of the code which doesn't include position info. > Can you conceive of some better scheme by which accurate line/column > numbers can be output by error messages, and which doesn't involve > rewriting the byte compiler? The =ABreal=BB solution, AFAIC, is to use a representation of the code where position-info is added to each node: - provide a new `read` function which provides something similar to `edebug-read` (and then change Edebug to use that function). - change macroexp to accept and return such a representation. - change byte-opt to accept and return such a representation. - change cconv to accept and return such a representation. - change bytecomp.el to accept representation. The changes to macroexp, byte-opt, cconv, and bytecomp aren't complicated and will be fairly repetitive, but they'll touch most of the code. > What I do anticipate about my hack is, assuming I ever get it working, > it will produce the correct source code positions all the time, not just > most of the time. It might work well in practice, yes. Tho using setc[ad]r like you suggest is risky since macros can return code which is a DAG rather than a tree (it's fairly unusual but not unheard of), so if you setc[ad]r on one side it might lead to nasty surprises on the other. Stefan