From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: setq's with missing final arguments. Date: Sun, 22 Nov 2015 19:44:44 +0000 Message-ID: <20151122194444.GD2332@acm.fritz.box> References: <20151122122657.GA2332@acm.fritz.box> <87egfi5h8i.fsf@igel.home> <87h9ke9o6x.fsf@fencepost.gnu.org> <87a8q65gd6.fsf@igel.home> <87d1v29nih.fsf@fencepost.gnu.org> <87610u5f9g.fsf@igel.home> <20151122141031.GB2332@acm.fritz.box> <83y4dq2g3s.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1448221384 12390 80.91.229.3 (22 Nov 2015 19:43:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Nov 2015 19:43:04 +0000 (UTC) Cc: dak@gnu.org, schwab@linux-m68k.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 22 20:42:55 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a0aXC-00018j-KV for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2015 20:42:50 +0100 Original-Received: from localhost ([::1]:57232 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0aXC-0006WF-FR for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2015 14:42:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39170) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0aX8-0006Va-LQ for emacs-devel@gnu.org; Sun, 22 Nov 2015 14:42:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a0aX5-00026F-Ep for emacs-devel@gnu.org; Sun, 22 Nov 2015 14:42:46 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:41111) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0aX5-000268-54 for emacs-devel@gnu.org; Sun, 22 Nov 2015 14:42:43 -0500 Original-Received: (qmail 48089 invoked by uid 3782); 22 Nov 2015 19:42:42 -0000 Original-Received: from acm.muc.de (p548A57CB.dip0.t-ipconnect.de [84.138.87.203]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 22 Nov 2015 20:42:41 +0100 Original-Received: (qmail 2178 invoked by uid 1000); 22 Nov 2015 19:44:44 -0000 Content-Disposition: inline In-Reply-To: <83y4dq2g3s.fsf@gnu.org> User-Agent: Mutt/1.5.23 (2014-03-12) 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 X-Received-From: 193.149.48.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:195058 Archived-At: Hello, Eli. On Sun, Nov 22, 2015 at 05:44:55PM +0200, Eli Zaretskii wrote: > > Date: Sun, 22 Nov 2015 14:10:31 +0000 > > From: Alan Mackenzie > > Cc: David Kastrup , emacs-devel@gnu.org > > > The byte-compiler is not for imposing coding style. > > That is why I proposed issuing a warning, not an error. In the actual > > case I found, it was indeed an error. > > > If it is wrong for setq to accept implit nil then it should be changed > > > in setq and only then in the byte-compiler. > > I would be happy enough for a missing final argument to setq to be an > > error. But until that stage is reached, I think issuing a warning is > > appropriate. But I disagree with you about priorities: it is more > > important to catch the violations in our compiled code than worry about > > the interpreted version. > As long as 'setq' accepts this use case, it is not a violation. It is a violation if it conceals errors. This indeed is the case: in .../lisp/emacs-lisp/bytecomp.el, in defun byte-compile-file-form-autoload the following erroneous code exists: (setq byte-compile-noruntime-functions (delq funsym byte-compile-noruntime-functions) byte-compile-noruntime-functions) . The effect is to set byte-compile-noruntime-functions unconditionally to nil. The effect of that is to conceal some "function not defined \(at runtime\)?" warnings in source files with `autoload' forms. There are four other occurrences of missing values in `setq's throughout the source (plus another one in .../obsolete). They all look like deliberate "coding style", though. If it were up to me, I would put an explicit nil in each of these four (or five) occurrences. I have changed the warning's wording to be more "human": it now says: missing value for `foo' at end of setq . But I do say that this warning facility I have in my personal copy should now be committed. It is useful. -- Alan Mackenzie (Nuremberg, Germany).