From patchwork Thu Jul 19 01:35:32 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jason Merrill X-Patchwork-Id: 171860 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]) by ozlabs.org (Postfix) with SMTP id 6520F2C00AB for ; Thu, 19 Jul 2012 11:36:05 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1343266566; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Mailing-List:Precedence: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=GJ+aXZPI+dQbqO0EaZJBcPtqcI8=; b=gTHjWTE+jLGHDDv nUnwnfyqiyBEtD/gRrH4rlpYfcwMnRJHahV1SOq3F5jPmwXEYpgaGc7EBIVlLywP BdiEHqllaaxSi9mgpNmrAmBMzRSai2ECpBzk8kRwk2Q7CcPRCASd+9OGDSwB5pWC s5FAYCShvlW4rPko6SlVVp2t5sMk= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=mmqV6vr17vx1Hi+v3jmy5vt8U9pPe6ncVGUrtJtrFzFdh/vyjWIl717aORFsyw ppQycLoI8yVZ3dfrpFH/4Z8+Yr2eByTMyWRVgql2vIVAHJa0ileAyY4A/pRvUQvi RGNxooFuJPQtJWWjuacqRW/FOTV6ZnUdJZv6g74zjVeG8=; Received: (qmail 31407 invoked by alias); 19 Jul 2012 01:36:02 -0000 Received: (qmail 31385 invoked by uid 22791); 19 Jul 2012 01:35:56 -0000 X-SWARE-Spam-Status: No, hits=-7.0 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, KHOP_THREADED, RCVD_IN_DNSWL_HI, RCVD_IN_HOSTKARMA_W, SPF_HELO_PASS, TW_CX, TW_FN, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 19 Jul 2012 01:35:34 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q6J1ZY4L005374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Jul 2012 21:35:34 -0400 Received: from [10.3.113.11] ([10.3.113.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q6J1ZWdi031246; Wed, 18 Jul 2012 21:35:33 -0400 Message-ID: <50076464.9010208@redhat.com> Date: Wed, 18 Jul 2012 21:35:32 -0400 From: Jason Merrill User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Paolo Carlini CC: "gcc-patches@gcc.gnu.org" Subject: Re: [C++ RFC / Patch] PR 51213 ("access control under SFINAE") References: <4FDB4640.3050502@oracle.com> <4FFF55EF.3090508@redhat.com> <4FFF587C.3050609@redhat.com> In-Reply-To: <4FFF587C.3050609@redhat.com> 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 On 07/12/2012 07:06 PM, Jason Merrill wrote: > I notice that your patch changes the behavior of C++98/03 mode as well, > which seems wrong to me; I think this is a big enough change that we > should limit it to C++11 mode. ...except that I can't figure out what the semantics before this DR were really supposed to be; G++, EDG and Clang all handle this stuff differently. After poking at it for a while I think the only sensible thing is to have C++03 work the same as C++11. I've done that, and I'm going to check in the full patch. The first attachment is the full patch; the second is the changes relative to your earlier patch. I changed tf_error to tf_warning_or_error, went back to treating C++03 and C++11 the same, made the FNDECL_RECHECK_ACCESS_P change I mentioned, and streamlined LOOKUP_SPECULATIVE handling. The third attachment is to fix another problem with my earlier DR 1402 patch. I'm applying this one to 4.7 as well. Finally, the fourth attachment is to remove the substitution checking from instantiate_decl, as it seems to be redundant. Tested x86_64-pc-linux-gnu, applying to trunk. commit c871e18c31fd94e9ee7ee983bedf50047dedfe60 Author: Jason Merrill Date: Wed Jul 18 18:37:17 2012 -0400 * pt.c (instantiate_decl): Don't recheck substitutions. diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c index 65eb2cc..0d25398 100644 --- a/gcc/cp/pt.c +++ b/gcc/cp/pt.c @@ -18248,35 +18248,6 @@ instantiate_decl (tree d, int defer_ok, if (TREE_CODE (d) == FUNCTION_DECL) maybe_instantiate_noexcept (d); - /* Recheck the substitutions to obtain any warning messages - about ignoring cv qualifiers. Don't do this for artificial decls, - as it breaks the context-sensitive substitution for lambda op(). */ - if (!defer_ok && !DECL_ARTIFICIAL (d)) - { - tree gen = DECL_TEMPLATE_RESULT (gen_tmpl); - tree type = TREE_TYPE (gen); - - /* Make sure that we can see identifiers, and compute access - correctly. D is already the target FUNCTION_DECL with the - right context. */ - push_access_scope (d); - - if (TREE_CODE (gen) == FUNCTION_DECL) - { - tsubst (DECL_ARGUMENTS (gen), gen_args, tf_warning_or_error, d); - tsubst_exception_specification (type, gen_args, tf_warning_or_error, - d, /*defer_ok*/true); - /* Don't simply tsubst the function type, as that will give - duplicate warnings about poor parameter qualifications. - The function arguments are the same as the decl_arguments - without the top level cv qualifiers. */ - type = TREE_TYPE (type); - } - tsubst (type, gen_args, tf_warning_or_error, d); - - pop_access_scope (d); - } - /* Defer all other templates, unless we have been explicitly forbidden from doing so. */ if (/* If there is no definition, we cannot instantiate the