From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [Patch] Enable byte-compile-error-on-wran for error-free files in lisp/ Date: Thu, 22 Feb 2018 09:13:07 +0200 Message-ID: <83mv015wfw.fsf@gnu.org> References: <87o9kii4an.fsf@cochranmail.com> <87371tn2qg.fsf@cochranmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1519283503 16975 195.159.176.226 (22 Feb 2018 07:11:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 22 Feb 2018 07:11:43 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Robert Cochran Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 22 08:11:39 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eol2Z-00041P-An for ged-emacs-devel@m.gmane.org; Thu, 22 Feb 2018 08:11:39 +0100 Original-Received: from localhost ([::1]:36519 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eol4b-0004ef-KC for ged-emacs-devel@m.gmane.org; Thu, 22 Feb 2018 02:13:45 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34422) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eol3o-0004dL-TJ for emacs-devel@gnu.org; Thu, 22 Feb 2018 02:12:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eol3l-00059g-M4 for emacs-devel@gnu.org; Thu, 22 Feb 2018 02:12:56 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33790) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eol3l-00059W-I3; Thu, 22 Feb 2018 02:12:53 -0500 Original-Received: from [176.228.60.248] (port=1399 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eol3k-0000UD-0w; Thu, 22 Feb 2018 02:12:52 -0500 In-reply-to: <87371tn2qg.fsf@cochranmail.com> (message from Robert Cochran on Wed, 21 Feb 2018 19:05:11 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:222981 Archived-At: > From: Robert Cochran > Date: Wed, 21 Feb 2018 19:05:11 -0800 > Cc: emacs-devel@gnu.org > > > I sometimes consider it preferable to keep a warning than to silence it > > (typically because I can't fix it (yet)). This said, I'm fine with > > adding such annotations for those files which currently don't have warnings. > > Yeah, right now it is only marking files that emit no warnings > whatsoever. I don't see why a file that today emits warnings should be exempted from the policy (if we accept it). I think the current state of affairs is entirely accidental, in the sense that it is the result of the fact that no one has seriously worked yet on the files that do emit warnings. So I find this aspect of the proposed change puzzling. Either we care about the warnings or we don't. If we do, we shouldn't tolerate them anywhere. > I intend for this to be a situation similar to lexical-binding, > where it is enabled on a per file as they get cleaned up and become > warning-free. Lack of lexical-binding was not an evidence of something being wrong with the file. So I don't see the analogy there. > I am trying to keep warnings from lingering. The > string-{to,as}-{multi,uni}byte family of functions have been deprecated > since June 2016, which are some of the functions I see the most in the > deprecation warnings. Stuff like that. I don't see how stopping the build will miraculously help us fix these warnings in a reasonably correct way. These warnings are hard to fix (see my other message about that). Moreover, there are warnings triggered by bugs or misfeatures in the byte compiler -- e.g., try byte-compiling gud.el. They can be shut up by kludgey workarounds, but do we really want our code to use such kludges, just to avoid the warnings? I predict that the result of making warnings stop the build will be abundance of kludges in the code, which will not be adequately explained in the sources, and so 10 years from now we will have the same situation as with string-to-unibyte, where no one really knows why we do that, and how to test whether the original reason is gone. IMO, the only way to eliminate the warnings is to start the work on fixing them one by one. This requires motivated individuals, and this requires time. Making warnings break the build is not the right way, IMO, it will just harm development by diverting part of our scarce resources to inventing kludges.