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: Time to merge scratch/correct-warning-pos into master, perhaps? Date: Sun, 23 Jan 2022 14:09:38 +0000 Message-ID: References: <84fspor0dj.fsf@gmail.com> <84o84bmxy2.fsf@gmail.com> <84sftfweck.fsf@gmail.com> 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="30899"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Brahimi Saifullah Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 23 15:12:50 2022 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 1nBdbu-0007qT-Qv for ged-emacs-devel@m.gmane-mx.org; Sun, 23 Jan 2022 15:12:50 +0100 Original-Received: from localhost ([::1]:48222 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nBdbt-0002rq-MR for ged-emacs-devel@m.gmane-mx.org; Sun, 23 Jan 2022 09:12:49 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:54246) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nBdYy-0001bp-SW for emacs-devel@gnu.org; Sun, 23 Jan 2022 09:09:48 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:49763 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1nBdYv-0007q3-Mr for emacs-devel@gnu.org; Sun, 23 Jan 2022 09:09:48 -0500 Original-Received: (qmail 62130 invoked by uid 3782); 23 Jan 2022 14:09:38 -0000 Original-Received: from acm.muc.de (p2e5d5e5b.dip0.t-ipconnect.de [46.93.94.91]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 23 Jan 2022 15:09:38 +0100 Original-Received: (qmail 12511 invoked by uid 1000); 23 Jan 2022 14:09:38 -0000 Content-Disposition: inline In-Reply-To: <84sftfweck.fsf@gmail.com> 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:285259 Archived-At: Hello, Brahimi. On Sat, Jan 22, 2022 at 20:16:43 -0300, Brahimi Saifullah wrote: > I'm very sorry for the noise, it seems I replied to the wrong Alan :( :-) I know the feeling. I'm massaging your post a bit and replying to it. > Alan Mackenzie writes: >> With the current state of the git branch, flymake on a .el file now >> seems to be working for me. > Yes, Flymake is working perfectly now. > I did notice an issue with the warning for unused forms: > value returned from (# 1 1) is unused > (from byte-compiling a file that consists of "(+ 1 1)") I'll look at that later today, thanks. > I expect that the symbol should be used, not the symbol with > positions. But it looks like this just got fixed a few hours ago > in master while my build was from before the merge. > While further testing this I also found a couple problems relating to > unused function arguments -- I'm unsure if they have anything to do with > the latest round of changes or not. > First, a bug: > (defun f (a b c) > ; ^^^ Warning: Unused lexical argument `a' > ; Warning: Unused lexical argument `b' > "A B C." > (+ 1 1)) > ; ^^^ Warning: Unused lexical argument `c' > You should be able to reproduce it by copying the above function > somewhere and byte compiling (sans the). Yes, no problem. That was a one-line correction to some hairy code which went to great lengths to get a correct (or close) warning position in the previous mechanism. Sorry about the mistake. I've committed the fix for this to master. > If the function consists of a single form, the position returned for > the last "unused lexical argument" will wrongly point to it. In this > example, the warning about C being unused will instead point to `+'. > The second issue is that, even when the unused lexical argument warnings > work correctly, they always point to the "defun," and not to the actual > argument in question. Not the end of the world of course, but it would > be nice for them to be more accurate. I think it's fixed now. Thank you indeed for the bug reports. >> Again, many thanks for the help. > And thanks for the work you've done, faulty warning > positions had always been an annoyance of mine :) -- Alan Mackenzie (Nuremberg, Germany).