From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65228 invoked by alias); 20 Apr 2015 03:28:23 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 65013 invoked by uid 89); 20 Apr 2015 03:28:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 20 Apr 2015 03:28:22 +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 t3K3SKmK003807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 19 Apr 2015 23:28:20 -0400 Received: from [10.10.116.43] ([10.10.116.43]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3K3SI8d008795; Sun, 19 Apr 2015 23:28:19 -0400 Message-ID: <5534724E.7000600@redhat.com> Date: Mon, 20 Apr 2015 03:28:00 -0000 From: Jason Merrill User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Adam Butcher CC: gcc-patches Subject: Re: [PATCH 1/2] PR c++/61636 References: <1428636694-6767-1-git-send-email-adam@jessamine.co.uk> <1428636694-6767-2-git-send-email-adam@jessamine.co.uk> <553165EA.70700@redhat.com> <2c51b8076a5ca562f87d7ba0ac8d5a70@imap.force9.net> <64e70a56f88e6269c16f8ba00de398da@imap.force9.net> In-Reply-To: <64e70a56f88e6269c16f8ba00de398da@imap.force9.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-04/txt/msg00982.txt.bz2 On 04/19/2015 03:03 PM, Adam Butcher wrote: > I think I need to resolve a member call within a generic lambda as if it > were not in template context to determine whether it unambiguously > resolves to a static member function. If it does, then no capture > required. Otherwise, 'this' should be captured because either a) the > call is to a non-static member function without any dependent parameters > or b) because it may resolve to a non-static member function at callop > instantiate time. Right. > No sure whether I can do all this at my current patch site in > cp_parser_postfix_expression or whether it needs to be later. I think it needs to be later, when the context of the lambda is fully instantiated, so that any other dependencies are resolved. Perhaps this means that we need to partially instantiate the (generic) lambda body... This is reminding me of bug 47226, though I'm not sure the fixes need to coordinate. Jason