From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artur Malabarba Newsgroups: gmane.emacs.devel Subject: Re: Fixing compilation and byte-compilation warnings before 25.1 Date: Mon, 16 Nov 2015 23:24:30 +0000 Message-ID: <8737w5zfwx.fsf@gmail.com> 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: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1447721828 26546 80.91.229.3 (17 Nov 2015 00:57:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Nov 2015 00:57:08 +0000 (UTC) Cc: emacs-devel To: daniel sutton Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 17 01:57:07 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 1ZyUZc-0006Io-Du for ged-emacs-devel@m.gmane.org; Tue, 17 Nov 2015 01:56:40 +0100 Original-Received: from localhost ([::1]:53521 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyUZb-00073v-W3 for ged-emacs-devel@m.gmane.org; Mon, 16 Nov 2015 19:56:40 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48203) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZySDC-0005li-Fx for emacs-devel@gnu.org; Mon, 16 Nov 2015 17:25:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZySD9-0002Yi-Al for emacs-devel@gnu.org; Mon, 16 Nov 2015 17:25:22 -0500 Original-Received: from mail-wm0-x22a.google.com ([2a00:1450:400c:c09::22a]:38536) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZySD9-0002YK-5X for emacs-devel@gnu.org; Mon, 16 Nov 2015 17:25:19 -0500 Original-Received: by wmec201 with SMTP id c201so306986wme.1 for ; Mon, 16 Nov 2015 14:25:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; bh=PTk7RD8Z7Ziic1yMUb6NARm/NlaW3bcuk0mU5VCShoc=; b=Nj5qmUUbhMTK24ucwNQzgorLzrG5BW74HqFJ/DIOBuYfTbypXQxSKrMQRFJcAislmA LUWAWJLhmNUTTlzMqGFJNqgL4GxyMUc/Ft2/DgQnk0xu8xI0tHhkIcdpMvhB7LkTnC1T 76O8jUpEnCLAxAn2xQqi7YNPy38GCl8NQ6XQAlo+EyYzr4IQGj5YgbZEdSfUUgZrvmtb 8E572Ckk+a7nj1P2lDa19x/P8ygumiznj8JGaQyxVwOFn7BM3dfSjqWBgcsRGab7ENpD SQLBDAjV5dz+6G5z+oxrnZV7Nj1YQQ6MvwJyH/oStuxrbv0Rzz+n+TKbD8dQyOHM8Pc3 S2iw== X-Received: by 10.28.128.210 with SMTP id b201mr20393030wmd.69.1447712718424; Mon, 16 Nov 2015 14:25:18 -0800 (PST) Original-Received: from Gandalf-Linux.gmail.com (host-92-12-87-116.as43234.net. [92.12.87.116]) by smtp.gmail.com with ESMTPSA id z10sm20624508wmg.4.2015.11.16.14.25.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Nov 2015 14:25:17 -0800 (PST) In-Reply-To: (daniel sutton's message of "Mon, 16 Nov 2015 08:15:59 -0600") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c09::22a 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:194605 Archived-At: daniel sutton writes: > 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 wouldn't do. This would mean that you would never get a callargs warning inside a function that declares `advertised-calling-convention', _even_ warnings that pertain to calls to _other_ functions.=20 So it would have to be smarter than that, and only suppress the warning if it pertains to this very 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. You should know, I don't think this sitation of =E2=80=9Cfunction with obso= lete calling convention that recursively calls itself=E2=80=9D is actually that common.=20 If you'd like to try your hand at this, by all means, have fun. :-) The cause sounds reasonable to me, as long as the solution doesn't turn out horribly complex it should be a nice addition. I just thought you should know that.