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: next steps. Date: Tue, 11 Dec 2018 13:43:32 -0800 Organization: UCLA Computer Science Department Message-ID: References: <20181210180033.GC4188@ACM> <20181211113420.GB4911@ACM> <20181211192001.GC4911@ACM> <20181211205128.GD4911@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 1544564537 11316 195.159.176.226 (11 Dec 2018 21:42:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 11 Dec 2018 21:42:17 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 11 22:42:13 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 1gWpn9-0002nV-Ay for ged-emacs-devel@m.gmane.org; Tue, 11 Dec 2018 22:42:11 +0100 Original-Received: from localhost ([::1]:41522 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWppF-00043N-UX for ged-emacs-devel@m.gmane.org; Tue, 11 Dec 2018 16:44:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50617) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWpoZ-000431-W7 for emacs-devel@gnu.org; Tue, 11 Dec 2018 16:43:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gWpoV-0000Si-0Z for emacs-devel@gnu.org; Tue, 11 Dec 2018 16:43:39 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:47168) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gWpoU-0000Rz-Mg for emacs-devel@gnu.org; Tue, 11 Dec 2018 16:43:34 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 72B5C1608EB; Tue, 11 Dec 2018 13:43:33 -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 gojGwWogoTze; Tue, 11 Dec 2018 13:43:32 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9714A1608F6; Tue, 11 Dec 2018 13:43:32 -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 XXQhFpycOjVn; Tue, 11 Dec 2018 13:43:32 -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 77F311608E7; Tue, 11 Dec 2018 13:43:32 -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: <20181211205128.GD4911@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:231768 Archived-At: On 12/11/18 12:51 PM, Alan Mackenzie wrote: > Let's just assume we can get a list of functions from somewhere. > Exactly how is a minor implementation detail. I only suggested objdump > to demonstrate it was possible and easy. I think the C compiler, any C > compiler, can generate cross references. That would be another source > of the info. I'm afraid that many C compilers don't generate cross references, and that this is not a minor implementation detail that we can assume away. >> That's OK, if the cost is borne only by people who want accurate >> diagnostics. People who want compilation speed can simply turn off the >> accurate-diagnostics flag. > WHAT???? There is no such flag, will be no such flag, MUST be no such > flag. We give accurate diagnostics to EVERYBODY, and we do this FAST. That would be nice, but if we can't do it quickly (without significant slowdowns elsewhere, or major contortions to the code) then perhaps we'll have to settle for accurate diagnostics as an option. > The byte compiler is well over 8000 lines of code, much, possibly > most, of which would need to be rewritten Although it would not be trivial to modify 8000 lines of code in a tedious but mostly-systematic way, that is not what I would call an enormous project. For perspective, the Emacs patch I'm currently hacking on (in a different area) is currently about 3000 lines and I wouldn't be surprised if it doubled before it's done. Sometimes even reasonably-minor conceptual changes require many tedious changes to the source code; that's just life when hacking. > I suggest you take on the task yourself, or organise a team Thanks, but this issue is not that high on my priority list. > people writing macros don't have to and mustn't have > to care about diagnostic mechanisms. Lisp hackers deserve to get the > best diagnostics without any such ugly compromises being made. As I understand it these annotations are not simply concessions to limitations of our location implementation; they also provide information that are useful for other reasons. I'm still not seeing examples of why it would be hard for users to provide the optional annotations, if they want the corresponding advantages.