From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: scratch/accurate-warning-pos: next steps. Date: Tue, 11 Dec 2018 20:51:28 +0000 Message-ID: <20181211205128.GD4911@ACM> References: <20181210180033.GC4188@ACM> <20181211113420.GB4911@ACM> <20181211192001.GC4911@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1544561760 25497 195.159.176.226 (11 Dec 2018 20:56:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 11 Dec 2018 20:56:00 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 11 21:55:56 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 1gWp4M-0006Ww-JW for ged-emacs-devel@m.gmane.org; Tue, 11 Dec 2018 21:55:54 +0100 Original-Received: from localhost ([::1]:41388 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWp6T-000671-Br for ged-emacs-devel@m.gmane.org; Tue, 11 Dec 2018 15:58:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40518) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWp5J-00064F-1a for emacs-devel@gnu.org; Tue, 11 Dec 2018 15:56:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gWp5F-0003Wq-O5 for emacs-devel@gnu.org; Tue, 11 Dec 2018 15:56:52 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:31253 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gWp5F-0003W1-Ch for emacs-devel@gnu.org; Tue, 11 Dec 2018 15:56:49 -0500 Original-Received: (qmail 88235 invoked by uid 3782); 11 Dec 2018 20:56:47 -0000 Original-Received: from acm.muc.de (p2E5D5A02.dip0.t-ipconnect.de [46.93.90.2]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 11 Dec 2018 21:56:46 +0100 Original-Received: (qmail 9265 invoked by uid 1000); 11 Dec 2018 20:51:28 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 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:231763 Archived-At: Hello, Paul. On Tue, Dec 11, 2018 at 11:59:27 -0800, Paul Eggert wrote: > On 12/11/18 11:20 AM, Alan Mackenzie wrote: > If we required objdump or similar utilities, that would be yet another > porting hassle. And we might run into platforms where there is no > objdump-like utility and we have to write one ourselves. This doesn't > sound good at all. 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. [ .... ] > >> It should be easy enough to move shared file-static data into another > >> file, that would be compiled only once. > > Possibly not. The same would have to be done with file global data, > > too. But doing it that way would involve a great deal of change to the > > source code (testing for the -D option) which would not be popular. > It'd be less change than having to decorate every function that might > call EQ. True, but an irrelevant diversion. Nobody but you is suggesting decorating every function. > > It would likely slow down the compilation by a very great deal. > 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. > > You're conflating "tedious" with "tedious in the extreme". > We're estimating how much work would be needed. Even if there would be > more work in changing the byte compiler, it shouldn't be so much more > work that we need to contort all the rest of Emacs. Nobody but you is talking about "contorting all the rest of Emacs". The byte compiler is well over 8000 lines of code, much, possibly most, of which would need to be rewritten. Writing the aforementioned preprocessor is MUCH less work. It is something I can do and intend to do. As for amending the reader and byte compiler to work with "Stefan's format", I know that that is beyond my hacking capacity, even if it could work. I suggest you take on the task yourself, or organise a team to do it. If at the end you have a working solution to the bug, we can compare approaches and merge the better one into the master branch. [ .... ] > > This would place onerous restrictions on what macros were allowed to do, > > and likely be incompatible with a vast proportion of existing macros. > But under both proposals I mentioned, existing macros would work just > fine with no new restrictions. So what I think you're saying is that if > people want to write macros that allow for more-accurate diagnostics, > they'll find that they can't easily do it for some reason. No, I'm saying that 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. -- Alan Mackenzie (Nuremberg, Germany).