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: Sat, 14 Nov 2015 12:22:38 -0600 Message-ID: References: <5645F670.9040601@online.de> <56460E2B.10603@cs.ucla.edu> <87io54c0es.fsf@web.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bdca44ecb721f05248442b2 X-Trace: ger.gmane.org 1447585871 19243 80.91.229.3 (15 Nov 2015 11:11:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 15 Nov 2015 11:11:11 +0000 (UTC) Cc: emacs-devel@gnu.org To: Michael Heerdegen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 15 12:11:04 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 1ZxvD4-0006Ai-BB for ged-emacs-devel@m.gmane.org; Sun, 15 Nov 2015 12:11:02 +0100 Original-Received: from localhost ([::1]:41910 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxvD3-0000Yr-Nt for ged-emacs-devel@m.gmane.org; Sun, 15 Nov 2015 06:11:01 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33407) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxfTE-0002G1-EU for emacs-devel@gnu.org; Sat, 14 Nov 2015 13:22:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZxfTD-0001BQ-72 for emacs-devel@gnu.org; Sat, 14 Nov 2015 13:22:40 -0500 Original-Received: from mail-ig0-x22a.google.com ([2607:f8b0:4001:c05::22a]:34336) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxfTD-0001BL-1m for emacs-devel@gnu.org; Sat, 14 Nov 2015 13:22:39 -0500 Original-Received: by igvg19 with SMTP id g19so54149680igv.1 for ; Sat, 14 Nov 2015 10:22:38 -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=aaXtdBK1S42cp39oI9KZQ1UMehekDVvzTEjmVsUMhzs=; b=1GECMxiYtXGvPWkoFBUmjTf/stQSOiwrOC3H+3hVW6ttsELSOxYhyoZ5n77K77PED+ n4PsGuCJywlhO2LRC3E9G3h3pQgYPOpTNg90+SFIdwPebon74Hbehs8nWL7KFoE3dH+f 2DKxHGPjA4plH3bcfG6Dp7iO3egz8XVNVIoesCaXjPx6Wd2SkTE/jgqUxcjKj3I9/8fE 18cb0bQ3EHBtymbXmTYHOi6mvPwzzQ4VsKwW41UaMKpNjH1T6S+N/En6H/zMuSv3WHNY EilAo2nQz0gYlydueEBKvTwG0XhWleTg4MzKAt2NKoDa7kKyMb9U6/tKKpxhRSV7PedJ CCvg== X-Received: by 10.50.61.230 with SMTP id t6mr9246214igr.28.1447525358463; Sat, 14 Nov 2015 10:22:38 -0800 (PST) Original-Received: by 10.107.15.229 with HTTP; Sat, 14 Nov 2015 10:22:38 -0800 (PST) In-Reply-To: <87io54c0es.fsf@web.de> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c05::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:194489 Archived-At: --047d7bdca44ecb721f05248442b2 Content-Type: text/plain; charset=UTF-8 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? One suggestion was to add the recursive call into a (with-no-warnings ...) call, but this could get tedious and invasive. Perhaps there could be a list of ignorable warnings that could be suppressed when in the core? On Sat, Nov 14, 2015 at 4:58 AM, Michael Heerdegen wrote: > daniel sutton writes: > > > Can someone help me understand why we are getting a compiler warning > > about seemingly valid usage of optional arguments? > > The cause is the defined `advertised-calling-convention' for > `display-completion-list'. Declaring an `advertised-calling-convention' > is the standard way to tell people that the signature of a function will > be changed in the future. It has been discussed some while ago whether > this way to provide this kind of information is appropriate. > > Anyway, as long as the old signature is supported, the recursive call > will probably have to break the new calling convention. > > > Michael. > > > --047d7bdca44ecb721f05248442b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 c= onsumers but not in the core. Would it be appropriate for the declare state= ment to somehow tell the compiler that we are in the core and therefore to = suppress warnings of this type? One suggestion was to add the recursive cal= l into a (with-no-warnings ...) call, but this could get tedious and invasi= ve.

Perhaps there could be a list of ignorable warnings = that could be suppressed when in the core?=C2=A0

On Sat, Nov 14, 2015 at 4:58 AM,= Michael Heerdegen <michael_heerdegen@web.de> wrote:<= br>
daniel sutton <danielsutton01@gmail.com> writ= es:

> Can someone help me understand why we are getting a compiler warning > about seemingly valid usage of optional arguments?

The cause is the defined `advertised-calling-convention' for
`display-completion-list'.=C2=A0 Declaring an `advertised-calling-conve= ntion'
is the standard way to tell people that the signature of a function will be changed in the future.=C2=A0 It has been discussed some while ago whethe= r
this way to provide this kind of information is appropriate.

Anyway, as long as the old signature is supported, the recursive call
will probably have to break the new calling convention.


Michael.



--047d7bdca44ecb721f05248442b2--