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: Incorrect byte compiler error/warning message positions. A possible fix. Date: Sun, 14 Nov 2021 19:13:04 +0000 Message-ID: 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="40154"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 14 20:14:15 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 1mmKxC-000AJi-Aa for ged-emacs-devel@m.gmane-mx.org; Sun, 14 Nov 2021 20:14:14 +0100 Original-Received: from localhost ([::1]:52406 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mmKxB-0007qM-4o for ged-emacs-devel@m.gmane-mx.org; Sun, 14 Nov 2021 14:14:13 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:37428) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mmKwK-00078p-L6 for emacs-devel@gnu.org; Sun, 14 Nov 2021 14:13:20 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:64990 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1mmKwI-0005vt-3j for emacs-devel@gnu.org; Sun, 14 Nov 2021 14:13:20 -0500 Original-Received: (qmail 25634 invoked by uid 3782); 14 Nov 2021 19:13:04 -0000 Original-Received: from acm.muc.de (p4fe159f0.dip0.t-ipconnect.de [79.225.89.240]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 14 Nov 2021 20:13:04 +0100 Original-Received: (qmail 8964 invoked by uid 1000); 14 Nov 2021 19:13:04 -0000 Content-Disposition: inline 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:279447 Archived-At: Hello, Emacs. The byte compiler reports wrong source positions in its error and warning messages; not every time, but perhaps most of the time. There are currently at least six open bugs for this problem, e.g. bug #22288. I fixed the problem at the end of 2018 by introducing a new Emacs type "symbol with position". The position component of these symbols was the position in the source code, generated by the reader. Such a position gave a correct source position for error/warning messages. Unfortunately, this fix slowed Emacs down a little, and for this reason it was rejected by the people here. The bug remains unfixed. The reason for the slowdown was the need for EQ continually to check a flag which stated whether or not symbols with position were currently active, which they weren't apart from when compiling. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; I've recently returned to the bug and believe the symbols with position idea can be made to work without the slowdown in EQ. In the new scheme it is no longer true that (eq # 'foo). The Lisp form for a function being compiled is manipulated as at present, only its symbols will have positions. These will get stripped out of the symbols before final code generation. The biggest problem is with macros, and I think I can solve this. Arguments to macros are used in two ways: (i) They are tested to see what code to generate. What I call "USE" (ii) They are returned as generated code, e.g. ",@body". Call this "MENTION". Clearly (i) won't work if the symbols have positions, (ii) needs the positions for possible messages. The answer to this is, whilst compiling the macro, to keep track of whether a use of an argument is for USE or for MENTION and to generate code to extract the bare symbol for USE. This will involve little more than having two or three dynamically bound variables to be tested throughout the byte compiler. There are mild complications, e.g. when a function contributes towards the MENTION. But these can be overcome. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; This proposed fix is going to be more complicated than the one from three years ago. It will be able to reuse a lot of code from that previous fix, though. I intend to work on this in the coming weeks. -- Alan Mackenzie (Nuremberg, Germany).