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: Sun, 25 Nov 2018 17:41:39 -0800 Organization: UCLA Computer Science Department Message-ID: <60ac9dfc-b540-89f9-68ea-ec7cceaa8511@cs.ucla.edu> 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> 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 1543196437 24963 195.159.176.226 (26 Nov 2018 01:40:37 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 26 Nov 2018 01:40:37 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 Cc: michael_heerdegen@web.de, eliz@gnu.org, emacs-devel@gnu.org, cpitclaudel@gmail.com, monnier@IRO.UMontreal.CA To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 26 02:40:32 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 1gR5t1-0006Q1-UP for ged-emacs-devel@m.gmane.org; Mon, 26 Nov 2018 02:40:32 +0100 Original-Received: from localhost ([::1]:33782 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gR5v8-00087M-J4 for ged-emacs-devel@m.gmane.org; Sun, 25 Nov 2018 20:42:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53757) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gR5uM-00085h-TK for emacs-devel@gnu.org; Sun, 25 Nov 2018 20:41:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gR5uL-0007YP-Ss for emacs-devel@gnu.org; Sun, 25 Nov 2018 20:41:54 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:60106) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gR5uA-0007K3-Tb; Sun, 25 Nov 2018 20:41:44 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 93F26160167; Sun, 25 Nov 2018 17:41:40 -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 hFdLYpFdIyNV; Sun, 25 Nov 2018 17:41:39 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id AFFE91601AB; Sun, 25 Nov 2018 17:41:39 -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 S5BE2XwznT4m; Sun, 25 Nov 2018 17:41:39 -0800 (PST) Original-Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 7B9141600FF; Sun, 25 Nov 2018 17:41:39 -0800 (PST) In-Reply-To: <20181125212920.GK27152@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:231379 Archived-At: Alan Mackenzie wrote: > Because of macros. These macros are typically already compiled. Even a compiled macro operates via the interpreter. So we could have a separate interpreter used only by the byte compiler. 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. > If you could come up with a solid proposal which would fix the bug > without slowing down Emacs at all, we'd all be most appreciative. I'm afraid I don't understand the bug well enough yet to know whether any proposal I can come up with would be "solid". For one thing, any method of outputting source-code locations will founder in the presence of macros. Even GCC, which tries to do a reasonably good job of this and isn't limited by the Lisp reader, doesn't do well with the sort of C macros I tend to write. My admittedly uninformed guess is that there is no such thing as a "solid" solution here, only solutions that work better and/or worse on various example sets. That being said, here's another possibility: don't bother attaching source-code positions to symbols, since duplicate symbols can be appear in the input and the source-code positions can't be retrieved reliably. Instead, attach positions to input objects that are guaranteed to be unique so that retrieval is trivial. Do the attachment via a hash table so that the input objects are unchanged and we don't need to change much of anything except the byte-compiler's diagnostic code (plus a read function that fills in the hash table as it reads). When the byte compiler needs the source code location corresponding to a symbol, it looks for the closest unique object nearby and uses its location. For example, the source expression for the bug#22288 test case: (defun test () (let (a)) a) has five conses in its top level list, two conses at the top of its second level list (let (a)), and one cons in its third level list (a). Each cons corresponds to a source code position (or if you prefer more accuracy, multiple positions for the start and end of the corresponding source-code and/or for the starts and ends of the source code corresponding to the cons's car and cdr). This will let the byte compiler narrow down where every subexpression lies, with significantly more accuracy than what we have now. In the bug#22288 example, the last cons in the top-level list should be attached to the precise source code location for the 'a' that we want to issue a diagnostic about.