From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps. Date: Mon, 26 Nov 2018 10:27:48 -0800 Organization: UCLA Computer Science Department Message-ID: References: <20181117124534.GA8831@ACM> <83muq7u9rk.fsf@gnu.org> <20181123130904.GA2916@ACM> <20181125193050.GH27152@ACM> <2c2ae483-3309-f79d-07a5-30af1f49058b@cs.ucla.edu> <20181125212920.GK27152@ACM> <60ac9dfc-b540-89f9-68ea-ec7cceaa8511@cs.ucla.edu> <20181126094800.GA4030@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1543256805 20688 195.159.176.226 (26 Nov 2018 18:26:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 26 Nov 2018 18:26:45 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 Cc: michael_heerdegen@web.de, eliz@gnu.org, cpitclaudel@gmail.com, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 26 19:26:41 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 1gRLah-0005Fi-Ea for ged-emacs-devel@m.gmane.org; Mon, 26 Nov 2018 19:26:39 +0100 Original-Received: from localhost ([::1]:38146 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRLco-0008Na-0y for ged-emacs-devel@m.gmane.org; Mon, 26 Nov 2018 13:28:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47763) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRLbv-0008Cv-KE for emacs-devel@gnu.org; Mon, 26 Nov 2018 13:27:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gRLbu-0005Ex-QF for emacs-devel@gnu.org; Mon, 26 Nov 2018 13:27:55 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:49906) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gRLbr-0005DH-6I; Mon, 26 Nov 2018 13:27:51 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 77B26160236; Mon, 26 Nov 2018 10:27:49 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id uWxWR1YmHDQY; Mon, 26 Nov 2018 10:27:48 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 939E5160276; Mon, 26 Nov 2018 10:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Jj58oxEaDm-d; Mon, 26 Nov 2018 10:27:48 -0800 (PST) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 72B1B160236; Mon, 26 Nov 2018 10:27:48 -0800 (PST) Openpgp: preference=signencrypt Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= xsFNBEyAcmQBEADAAyH2xoTu7ppG5D3a8FMZEon74dCvc4+q1XA2J2tBy2pwaTqfhpxxdGA9 Jj50UJ3PD4bSUEgN8tLZ0san47l5XTAFLi2456ciSl5m8sKaHlGdt9XmAAtmXqeZVIYX/UFS 96fDzf4xhEmm/y7LbYEPQdUdxu47xA5KhTYp5bltF3WYDz1Ygd7gx07Auwp7iw7eNvnoDTAl KAl8KYDZzbDNCQGEbpY3efZIvPdeI+FWQN4W+kghy+P6au6PrIIhYraeua7XDdb2LS1en3Ss mE3QjqfRqI/A2ue8JMwsvXe/WK38Ezs6x74iTaqI3AFH6ilAhDqpMnd/msSESNFt76DiO1ZK QMr9amVPknjfPmJISqdhgB1DlEdw34sROf6V8mZw0xfqT6PKE46LcFefzs0kbg4GORf8vjG2 Sf1tk5eU8MBiyN/bZ03bKNjNYMpODDQQwuP84kYLkX2wBxxMAhBxwbDVZudzxDZJ1C2VXujC OJVxq2kljBM9ETYuUGqd75AW2LXrLw6+MuIsHFAYAgRr7+KcwDgBAfwhPBYX34nSSiHlmLC+ KaHLeCLF5ZI2vKm3HEeCTtlOg7xZEONgwzL+fdKo+D6SoC8RRxJKs8a3sVfI4t6CnrQzvJbB n6gxdgCu5i29J1QCYrCYvql2UyFPAK+do99/1jOXT4m2836j1wARAQABzSBQYXVsIEVnZ2Vy dCA8ZWdnZXJ0QGNzLnVjbGEuZWR1PsLBfgQTAQIAKAUCTIByZAIbAwUJEswDAAYLCQgHAwIG FQgCCQoLBBYCAwECH In-Reply-To: <20181126094800.GA4030@ACM> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 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:231405 Archived-At: On 11/26/18 1:48 AM, Alan Mackenzie wrote: > >> The byte-compiler >> interpreter would operate more slowly than the normal interpreter, but >> that's OK. The main and the byte-compiler interpreter could mostly be >> written with shared code, without slowing down the main interpreter. >> Admittedly this would not be a project for the fainthearted. > Indeed not. Where and how would this help with getting accurate source > code positions? From the point of view of the byte-compiler, it should help just as well as scratch/accurate-warning-pos does, because it's just another way to get the same information. Admittedly it's more work to implement this. >> any method of outputting source-code locations will founder in the >> presence of macros. > scratch/accurate-warning-pos seems to do rather well in this regard. No doubt it does better than master does. However, macros inevitably cause problems when diagnosing problems. If there's a bug in a macro, it could well be that the byte compiler will report the line number of the call to the macro rather than of the macro itself (where the real bug is). So any definition of a "solid" solution must provide some leeway for the compiler to issue a "wrong" diagnostic when macros are involved. Otherwise, if the goal is to provide a "solid" solution then the goalposts will keep moving and there's no way that I could suggest a solution that is unambiguously "solid". >> Instead, attach positions to input objects that are guaranteed to be >> unique so that retrieval is trivial. > I think you mean conses here. I've tried this approach, spending a lot > of time on it but not getting very far. The problem is, Lisp objects > flow through lots of different conses as they are transformed by the > compiler. Have a look at cconv-convert, which processes every function. I took a brief look there and see a lot of calls to mapcar, which of course would lose track of locations. But this should be fixable by defining and using a new function mapcar-pos, which acts like mapcar except it also copies location information from the input list's conses to the corresponding conses in the output list. You're right that this would involve many changes to the byte compiler, but the changes should be reasonably mechanical (e.g., change mapcar to mapcar-pos) and the overall approach should be preferable to changing how 'eq' works. > The approach I tried > before to implement this was to ensure that after any source > transformation, the result was written back to the original cons using > setcar and setcdr. If location info is kept in a hash table that maps objects to locations, then mapcar-pos can preserve location info merely by updating a hash table. There should be no need for setcar and setcdr on the original cons.