From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Incorrect byte compiler error/warning message positions. A possible fix. Date: Tue, 16 Nov 2021 17:05:42 +0000 Message-ID: References: <87sfvy2dsl.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26289"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 16 18:09:27 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mn1xX-0006jN-A4 for ged-emacs-devel@m.gmane-mx.org; Tue, 16 Nov 2021 18:09:27 +0100 Original-Received: from localhost ([::1]:44794 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mn1xW-00077j-5e for ged-emacs-devel@m.gmane-mx.org; Tue, 16 Nov 2021 12:09:26 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:35198) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mn1uG-0001ut-9h for emacs-devel@gnu.org; Tue, 16 Nov 2021 12:06:06 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:26248 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1mn1uD-0001gJ-Q9 for emacs-devel@gnu.org; Tue, 16 Nov 2021 12:06:04 -0500 Original-Received: (qmail 3059 invoked by uid 3782); 16 Nov 2021 17:05:43 -0000 Original-Received: from acm.muc.de (p4fe15759.dip0.t-ipconnect.de [79.225.87.89]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 16 Nov 2021 18:05:42 +0100 Original-Received: (qmail 7656 invoked by uid 1000); 16 Nov 2021 17:05:42 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:279575 Archived-At: Hello, Stefan. On Mon, Nov 15, 2021 at 16:19:47 -0500, Stefan Monnier wrote: > >> In my experience, the vast majority of the warning messages point to the > >> correct position. But, yes, it does sometimes give the wrong position. > > On 2018-11-22 (before you destroyed my test dataset by fixing all the > > warnings in Emacs ;-) there were 335 warnings. 81 gave the correct > > location, 254 a wrong one. > FWIW, I think the current code gives (statistically) slightly less bad > positions, because of changes I've made to `cconv` and `bytecomp`. > That may explain Lars's impression. > Our positions are still too often poor. Some of us have just grown used > to missing or poor location info and don't notice them any more :-( I'm now fundamentally opposed to the use of terms like "poor" and "inaccurate" here. I prefer "wrong". ;-) > > They should be fairly easy (if, perhaps, tedious) to solve, because > > everything is under our control. > Agreed. > > It's macros where people outside of our control do wierd and wonderful > > things. I think I know how to compile macros so that they both work, > > yet preserve the symbols with position on the code they generate. > > These compiled macros won't work on earlier versions of Emacs, but > > that's a bridge to cross when we come to it. > I'm curious know how you intend to make it work, While a macro is being compiled it will use a dynamically bound variable called, say, byte-comp-use. When non-nil, it indicates the macro may/should return executable code (i.e. without symbols with position). When nil, byte-comp-use instructs the macro to return "code" containing symbols with position, enabling the calling byte compiler to output these positions in warning messages. As macros call other macros, special forms in a macro will be enhanced to bind byte-comp-use appropriately. For example, in a progn (whose last form is the result code), byte-comp-use will be t for all subforms except the last. In an `if' whose two arms are alternative result codes, the condition form would have b-c-use t, each of the arms would have nil. Or something like that. An alternative/additional idea is to have things like the evaluator handle a symbol with position natively. This would not slow Emacs down the way amending EQ did three years ago; it would merely slow down the generation of code from macros, probably not by very much. > Stefan -- Alan Mackenzie (Nuremberg, Germany).