From patchwork Fri Feb 17 04:50:58 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Sandra Loosemore X-Patchwork-Id: 729003 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3vPgbZ5fHbz9s8J for ; Fri, 17 Feb 2017 15:51:37 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="VkBEbPUH"; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-type; q=dns; s=default; b=t0cASX28iHdQVo/hS U+ObzMFTivTjdLvGWc03mq0S/Xzaziyo3FpZMD/qlZIYrtu81nQ+ZwW8KTpRZ30O zVwHyRzRQn2Clm8baNSDqhT1K4qbBfBMX2e9SuKhCT7ClQHlqPOdNmtyEkJcYVYX Rd39mnsAKBeboTVI94JjHWQD4c= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-type; s=default; bh=ol1zFarvTmDDIuG7TlJNp7I QbDc=; b=VkBEbPUH342O4FvmRHVvIIitGpMn+zqkZDH1KD/Ycrap5jrVLuCRDWW dsmdKZV1/344Vtohe+RLgKu4MN2Ljzd9ZZXOEmYy0AV+1MrpliK+FKc6tMPs9hJk Iorv/gRg2PDSSOOjopldy9Si4e6HIGF/j4UBg8pteNf0vmYkZo5w= Received: (qmail 37802 invoked by alias); 17 Feb 2017 04:51:25 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 37081 invoked by uid 89); 17 Feb 2017 04:51:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-15.3 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS, URIBL_RED autolearn=ham version=3.3.2 spammy=H*f:sk:CAH6eHd, explanations, friend X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 17 Feb 2017 04:51:07 +0000 Received: from svr-orw-mbx-03.mgc.mentorg.com ([147.34.90.203]) by relay1.mentorg.com with esmtp id 1ceaVc-0000pa-1I from Sandra_Loosemore@mentor.com ; Thu, 16 Feb 2017 20:51:04 -0800 Received: from [127.0.0.1] (147.34.91.1) by svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 16 Feb 2017 20:51:00 -0800 Subject: [doc, committed] Re: Doc question: is "templatized" a word? To: Jason Merrill , Jonathan Wakely References: <589E8ED2.5070903@codesourcery.com> <589F75BA.7050109@codesourcery.com> CC: Gerald Pfeifer , "gcc-patches@gcc.gnu.org" From: Sandra Loosemore Message-ID: <58A68132.5060106@codesourcery.com> Date: Thu, 16 Feb 2017 21:50:58 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: X-ClientProxiedBy: svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) To svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) On 02/15/2017 01:17 PM, Jason Merrill wrote: > On Wed, Feb 15, 2017 at 1:57 PM, Jonathan Wakely wrote: >> On 15 February 2017 at 15:53, Jason Merrill wrote: >>> On Sat, Feb 11, 2017 at 4:19 PM, Jonathan Wakely wrote: >>>> On 11 February 2017 at 20:36, Sandra Loosemore wrote: >>>>> On 02/11/2017 06:21 AM, Jonathan Wakely wrote: >>>>>> >>>>>> On 11 February 2017 at 08:48, Gerald Pfeifer wrote: >>>>>>> >>>>>>> On Fri, 10 Feb 2017, Sandra Loosemore wrote: >>>>>>>> >>>>>>>> The documentation for -Wno-non-template-friend refers to >>>>>>>> "non-templatized >>>>>>>> friend functions" and "templatized functions". I don't see the term >>>>>>>> "templatized" used anywhere in the C++ standard. This paragraph also >>>>>>>> uses >>>>>>>> "nontemplate function", which I assume refers to the same thing the C++ >>>>>>>> standard spells "non-template function". So does "non-templatized >>>>>>>> function" >>>>>>>> also mean "non-template function"? Or does it have some other meaning? >>>>>>> >>>>>>> >>>>>>> I would avoid "templatized" and believe "non-template function" is >>>>>>> more appropriate in your example. >>>>>> >>>>>> >>>>>> Yes, >>>>>> >>>>>> s/non-templatized/non-template/ >>>>>> s/nontemplate/non-template/ >>>>>> s/templatized function/function template/ >>>>>> >>>>>> But I wonder if that warning is even useful nowadays. The example of >>>>>> "friend foo(int);" is bogus and is correctly rejected: >>>>>> >>>>>> fr.cc:2:17: error: ISO C++ forbids declaration of ‘foo’ with no type >>>>>> [-fpermissive] >>>>>> friend foo(int); >>>>>> ^ >>>>> >>>>> >>>>> I hadn't actually gotten that far :-) but it looks like that's an >>>>> implicit-int error unrelated to the actual purpose of this option. >>>>> >>>>> This ended up on my todo list firstly because "templatized" didn't >>>>> spell-check, and secondly because the "new compiler behavior" documented in >>>>> connection with this option has existed at least since 1998 and can hardly >>>>> be considered "new" any more. Also I think the reference to section 14.5.3 >>>>> of the C++ standard is bit-rotten (it's 14.5.4 in the c++0x draft I have >>>>> handy). >>>>> >>>>> I'll leave it up to the C++ experts to decide whether the option should just >>>>> be removed and the warning replaced with a hard error controlled by some >>>>> other flag. >>>> >>>> It definitely shouldn't be turned into a hard error, the warning >>>> complains about valid code, such as: >>>> >>>> template struct A { >>>> friend int foo(T); >>>> }; >>>> >>>> int main() { >>>> A a; >>>> } >>>> >>>> I think it warns because the meaning of that code changed, a *long* >>>> time ago, so it's saying "if you wrote this code in the 1990s it might >>>> do something different to what you expect." >>>> >>>> I'm not sure how useful that warning is now, although EDG warns for it >>>> too (with a fix-it hint that I think is bogus): >>>> >>>> "fr.cc", line 2: warning: "int foo(T)" declares a non-template function -- add >>>> <> to refer to a template instance >>>> friend int foo(T); >>>> ^ >>> >>> That fix-it looks fine to me; >> >> Where should I add the <> to make it valid? >> >> If I change the example to "friend int foo<>(T);" EDG says it's not a template: >> >> template struct A { >> friend int foo<>(T); >> }; >> >> int main() { >> A a; >> } >> >> "fr.cc", line 2: error: foo is not a template >> friend int foo<>(T); > > Yep, you would also need to declare the foo template earlier in the TU. > > Jason > Thanks everyone for the explanations and suggestions. I've checked in the attached patch to clean this up. -Sandra Index: gcc/doc/invoke.texi =================================================================== --- gcc/doc/invoke.texi (revision 245524) +++ gcc/doc/invoke.texi (working copy) @@ -2996,19 +2996,13 @@ But this use is not portable across diff @item -Wno-non-template-friend @r{(C++ and Objective-C++ only)} @opindex Wno-non-template-friend @opindex Wnon-template-friend -Disable warnings when non-templatized friend functions are declared -within a template. Since the advent of explicit template specification -support in G++, if the name of the friend is an unqualified-id (i.e., -@samp{friend foo(int)}), the C++ language specification demands that the -friend declare or define an ordinary, nontemplate function. (Section -14.5.3). Before G++ implemented explicit specification, unqualified-ids -could be interpreted as a particular specialization of a templatized -function. Because this non-conforming behavior is no longer the default -behavior for G++, @option{-Wnon-template-friend} allows the compiler to -check existing code for potential trouble spots and is on by default. -This new compiler behavior can be turned off with -@option{-Wno-non-template-friend}, which keeps the conformant compiler code -but disables the helpful warning. +Disable warnings when non-template friend functions are declared +within a template. In very old versions of GCC that predate implementation +of the ISO standard, declarations such as +@samp{friend int foo(int)}, where the name of the friend is an unqualified-id, +could be interpreted as a particular specialization of a template +function; the warning exists to diagnose compatibility problems, +and is enabled by default. @item -Wold-style-cast @r{(C++ and Objective-C++ only)} @opindex Wold-style-cast