From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: daniel sutton Newsgroups: gmane.emacs.devel Subject: Re: Fixing compilation and byte-compilation warnings before 25.1 Date: Mon, 16 Nov 2015 08:15:59 -0600 Message-ID: References: <5645F670.9040601@online.de> <56460E2B.10603@cs.ucla.edu> <87io54c0es.fsf@web.de> <87ziyfsadz.fsf@web.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113f8f3c690c2c0524a90c7f X-Trace: ger.gmane.org 1447707629 3091 80.91.229.3 (16 Nov 2015 21:00:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 Nov 2015 21:00:29 +0000 (UTC) Cc: emacs-devel To: Michael Heerdegen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 16 22:00:29 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 1ZyQt2-0008K3-4h for ged-emacs-devel@m.gmane.org; Mon, 16 Nov 2015 22:00:28 +0100 Original-Received: from localhost ([::1]:49389 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyQsw-00078F-NJ for ged-emacs-devel@m.gmane.org; Mon, 16 Nov 2015 16:00:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36687) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyKZi-0004c7-HR for emacs-devel@gnu.org; Mon, 16 Nov 2015 09:16:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZyKZc-0006kc-GZ for emacs-devel@gnu.org; Mon, 16 Nov 2015 09:16:06 -0500 Original-Received: from mail-io0-x235.google.com ([2607:f8b0:4001:c06::235]:34794) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyKZc-0006kX-AF for emacs-devel@gnu.org; Mon, 16 Nov 2015 09:16:00 -0500 Original-Received: by ioir85 with SMTP id r85so119871536ioi.1 for ; Mon, 16 Nov 2015 06:15:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IAROF0v4DDQ4Tu6cTSsbYStGZ8riXbdLIhBntStHU/0=; b=uo6wmyLBZmRt0kTaGkQJlGKb3hIKAP8OgIqMI3RsCe7DKkx91JDIULnDXz/m34+SGe HmEBTugd8wXs09yDlS0A2eWhqP0E2Lf5it8lDJI78PZYh1mKimEWvTamq35XXiLZxuuM LyCfk7g5Xx2K/KVmrEvWmgYqRmcNGI9YBVYOmxG3QftBFcoVZKi5Acr6IIuK/LxLvN83 KCmN2LJ2B/1JGVdMpHVTZWpp8fZstWA6J6QA2XqNFEhy6n/9C3EMEeXLR+CZNXIuCOYf beZo6tiFNKvoryk3p+/9ONJz1Y7Gip1885FnZpm3g2GSWCtiROAzO/C06+NBspYhMxLM t+Ow== X-Received: by 10.107.8.69 with SMTP id 66mr36763561ioi.34.1447683359835; Mon, 16 Nov 2015 06:15:59 -0800 (PST) Original-Received: by 10.107.15.229 with HTTP; Mon, 16 Nov 2015 06:15:59 -0800 (PST) In-Reply-To: <87ziyfsadz.fsf@web.de> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c06::235 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:194548 Archived-At: --001a113f8f3c690c2c0524a90c7f Content-Type: text/plain; charset=UTF-8 There could be some value to that. My thinking is that the declaration that there should be only one argument passed is kinda like a keep off the grass sign, but then the compiler is throwing a warning that the keep off the grass sign is actually on the grass. The consumers of this should have a warning, but since we are handling legacy behavior (of passing two arguments) there should be no warning inside of this function. When things change, ie, if we remove the optional argument, then we would immediately know if we forgot to change things because then this would be an error, as the argument mismatch was very obvious. I certainly agree that blindly suppressing all warnings is not a good call. I'm investigating the way that the compiler works, as I'm very new to this. My thinking is that we may have local definitions of byte-compile-enable-warnings that include (not callargs) *only* when compiling a function that contains a (declare (advertised-calling-convention (newArgs) "version")). This would make sure that others that hit this would be warned about the api shift but allow "bad" calls to it to still work. Then, when the optional argument is finally removed, if someone forgot to remove the old call, again, inside of the original defun, it would be a compiler error and not warning. But presumably, if you are changing the function signature like this you would be responsible for the entire body of the function. Again, this is a proposal only for this specific type of warning, and not just suppressing warnings inside of the core. I want warnings to be informative and a cause of action, not to be ignored. This warning is superfluous and should be removed. If the best case is just a (with-no-warnings ...) so be it, but I think there is a more clever solution here, and one that actually fits the nature of what is being done with a advertised-calling-convention change. On Sun, Nov 15, 2015 at 6:41 AM, Michael Heerdegen wrote: > daniel sutton writes: > > > Ah thank you. Someone responded and made a new thread and were super > > helpful as well. It seems like this warning needs to go to new > > consumers but not in the core. Would it be appropriate for the declare > > statement to somehow tell the compiler that we are in the core and > > therefore to suppress warnings of this type? > > I don't think that suppressing blindly all warnings of any particular > type is a good idea. Some of them might indicate problems. > > > One suggestion was to add the recursive call into a (with-no-warnings > > ...) call, but this could get tedious and invasive. > > Why not just leave this one particular warning? It reminds us we still > have something to change there in the future. > > > Michael. > > > --001a113f8f3c690c2c0524a90c7f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There could be some value to that. My thinking is that the= declaration that there should be only one argument passed is kinda like a = keep off the grass sign, but then the compiler is throwing a warning that t= he keep off the grass sign is actually on the grass. The consumers of this = should have a warning, but since we are handling legacy behavior (of passin= g two arguments) there should be no warning inside of this function. When t= hings change, ie, if we remove the optional argument, then we would immedia= tely know if we forgot to change things because then this would be an error= , as the argument mismatch was very obvious.=C2=A0

I cer= tainly agree that blindly suppressing all warnings is not a good call. I= 9;m investigating the way that the compiler works, as I'm very new to t= his. My thinking is that we may have local definitions of byte-compile-enab= le-warnings that include (not callargs) *only* when compiling a function th= at contains a (declare (advertised-calling-convention (newArgs) "versi= on")). This would make sure that others that hit this would be warned = about the api shift but allow "bad" calls to it to still work. Th= en, when the optional argument is finally removed, if someone forgot to rem= ove the old call, again, inside of the original defun, it would be a compil= er error and not warning. But presumably, if you are changing the function = signature like this you would be responsible for the entire body of the fun= ction.

Again, this is a proposal only for this spe= cific type of warning, and not just suppressing warnings inside of the core= . I want warnings to be informative and a cause of action, not to be ignore= d. This warning is superfluous and should be removed. If the best case is j= ust a (with-no-warnings ...) so be it, but I think there is a more clever s= olution here, and one that actually fits the nature of what is being done w= ith a advertised-calling-convention change.

On Sun, Nov 15, 2015 at 6:41 AM, Mich= ael Heerdegen <michael_heerdegen@web.de> wrote:
daniel sutton <danielsutton01@gmail.com> writes:
> Ah thank you. Someone responded and made a new thread and were super > helpful as well. It seems like this warning needs to go to new
> consumers but not in the core. Would it be appropriate for the declare=
> statement to somehow tell the compiler that we are in the core and
> therefore to suppress warnings of this type?

I don't think that suppressing blindly all warnings of any parti= cular
type is a good idea.=C2=A0 Some of them might indicate problems.

> One suggestion was to add the recursive call into a (with-no-warnings<= br> > ...) call, but this could get tedious and invasive.

Why not just leave this one particular warning?=C2=A0 It reminds us = we still
have something to change there in the future.


Michael.



--001a113f8f3c690c2c0524a90c7f--