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.bugs Subject: bug#73725: Master: Wrong position for byte compiler warning message. Date: Sat, 12 Oct 2024 10:47:53 +0000 Message-ID: References: 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="7785"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 73725@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 12 12:56:05 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1szZn3-0001tw-3E for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 12 Oct 2024 12:56:05 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1szZmp-0005ks-1k; Sat, 12 Oct 2024 06:55:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1szZmm-0005kI-DN for bug-gnu-emacs@gnu.org; Sat, 12 Oct 2024 06:55:48 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1szZmm-0001wy-3x for bug-gnu-emacs@gnu.org; Sat, 12 Oct 2024 06:55:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=From:In-Reply-To:MIME-Version:References:Date:To:Subject; bh=cZiztt8dUKWcWHJFGeuwgZssjF1Uv6DZfEmxbmnznM8=; b=UJtFrQeJN+O6ac3AwKUpm6Rwej4B+H9yKHKt8idb2cvGGCwe/5fvuvd6iFNDmlDLKS4Cq2nOi26VF4dULChBeLYxTx39+KgwUb1P3kUT6hOZajsmZMefpQYMoNhmxWCjYvxhAHN28wpvmmO92teeApXr6r+uTIxekuDriCcFxijZ36ufIvBSCILEcpASog7ODACHo/sVzEjTUXkQ0EBXzqdbSSjsK3cf18TKqQ7uqJ7F0EiZvXduckMNyTO+lCRQi2s4diNachmfM0nLm56wJFwJoHhc0LPQRz+jjmabIYVC/SGt5Fsf6RcB64i020/bpMoIlJy7SNzboBEO3u+pRw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1szZmz-0005Un-Pu for bug-gnu-emacs@gnu.org; Sat, 12 Oct 2024 06:56:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Oct 2024 10:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73725 X-GNU-PR-Package: emacs Original-Received: via spool by 73725-submit@debbugs.gnu.org id=B73725.172873051620488 (code B ref 73725); Sat, 12 Oct 2024 10:56:01 +0000 Original-Received: (at 73725) by debbugs.gnu.org; 12 Oct 2024 10:55:16 +0000 Original-Received: from localhost ([127.0.0.1]:38222 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1szZmG-0005KL-0i for submit@debbugs.gnu.org; Sat, 12 Oct 2024 06:55:16 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:60226) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1szZfU-0004qz-R7 for 73725@debbugs.gnu.org; Sat, 12 Oct 2024 06:48:17 -0400 Original-Received: (qmail 47348 invoked by uid 3782); 12 Oct 2024 12:47:55 +0200 Original-Received: from muc.de (p4fe156e7.dip0.t-ipconnect.de [79.225.86.231]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 12 Oct 2024 12:47:54 +0200 Original-Received: (qmail 6318 invoked by uid 1000); 12 Oct 2024 10:47:53 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:293410 Archived-At: Hello, Stefan. Thanks for the reply! On Fri, Oct 11, 2024 at 19:45:18 -0400, Stefan Monnier wrote: > > (i) Create the following file, bad-error-position2.el: > > ######################################################################### > > ;; -*- lexical-binding:t -*- > > (eval-and-compile > > (defmacro increase () > > `(let ((foo (point-max))) > > (cond > > ((consp foo) > > (message "consp %s" foo) > > foo) > > ((numberp foo) > > (1+ fooo)) ; Note the misspelling. > > (t (message "Something else: %s" foo)))))) > > (defun call-increase (bar) > > (cond > > ((not (or (consp bar) > > (numberp bar))) > > bar) > > (t (increase)))) > > ######################################################################### > > Note the misspelling of `foo' as `fooo' on line 10. > > (ii) emacs -Q > > (iii) M-x byte-compile-file /path/to/bad-error-position2.el. > > (iv) This gives the warning message: > > bad-error-position2.el:14:4: Warning: reference to free variable `fooo' > > (v) The position 14:4 is wrong. That is the position of the `cond' > > symbol in `call-increase'. > > (vi) The correct message should be: > > bad-error-position2.el:18:8: Warning: reference to free variable `fooo' > > .. 18:8 is the position of `increase' on the last line of the file. > Nitpick: one could also argue that the "correct" message should point to > line 8 where is the `fooo` typo. > > +(defun sub-macroexp--posify-form (form call-pos depth) > > + "Try to apply the transformation of `macroexp--posify-form' to FORM. > > +FORM and CALL-POS are as in that function. DEPTH is a small integer, > > +decremented at each recursive call, to prevent infinite recursion. > > +Return the changed form, or nil if no change happened." > > + (let (new-form > > + ) > > + (cond > > + ((zerop depth) nil) > > + ((and (consp form) > > + (symbolp (car form)) > > + (car form)) > > + (setcar form (position-symbol (car form) call-pos)) > > + form) > > + ((consp form) > > + (or (when (setq new-form (sub-macroexp--posify-form > > + (car form) call-pos (1- depth))) > > + (setcar form new-form) > > + form) > > + (when (setq new-form (sub-macroexp--posify-form > > + (cdr form) call-pos (1- depth))) > > + (setcdr form new-form) > > + form))) > > + ((symbolp form) > > + (if form ; Don't position nil! > > + (position-symbol form call-pos))) > > + ((and (or (vectorp form) (recordp form))) > > + (let ((len (length form)) > > + (i 0) > > + ) > > + (while (and (< i len) > > + (not (setq new-form (sub-macroexp--posify-form > > + (aref form i) call-pos (1- depth))))) > > + (setq i (1+ i))) > > + (when (< i len) > > + (aset form i new-form) > > + form)))))) > That sounds potentially costly Have you tried to measure the > performance impact in some "typical" cases? I haven't measured it, no, but I doubt it will be costly - the recursion in sub-macroexp--posify-form will very rarely occur. Virtually every form passed to it will by a macro invocation or a symbol, I think. > While reading your description I was naively thinking: we can > probably fix it with a trivial patch like: > diff --git a/lisp/emacs-lisp/macroexp.el b/lisp/emacs-lisp/macroexp.el > index 19daa57b207..5cc471e32f6 100644 > --- a/lisp/emacs-lisp/macroexp.el > +++ b/lisp/emacs-lisp/macroexp.el > @@ -246,6 +246,7 @@ macroexp-macroexpand > (let* ((macroexpand-all-environment env) > new-form) > (while (not (eq form (setq new-form (macroexpand-1 form env)))) > + (push form byte-compile-form-stack) > (let ((fun (car-safe form))) > (setq form > (if (and fun (symbolp fun) > Have you tried something like this? I haven't, no. It might well work. But I think the `push' form should go outside of the loop, I'm also a little wary about pushing an item onto stack when it doesn't get popped again after the form(s) it is "guarding". > If it doesn't work, do you happen to know why? I'm not sure whether it would work for the (similar) bug, bug#73746, where the symbols with position were getting lost in byte-opt.el. But I'll give it a try. I'm a bit busy in the next few days, so it might be next week before I manage it. > Stefan -- Alan Mackenzie (Nuremberg, Germany).