From patchwork Fri May 27 19:25:26 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jason Merrill X-Patchwork-Id: 97740 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 131FDB6F81 for ; Sat, 28 May 2011 05:25:43 +1000 (EST) Received: (qmail 4687 invoked by alias); 27 May 2011 19:25:42 -0000 Received: (qmail 4653 invoked by uid 22791); 27 May 2011 19:25:41 -0000 X-SWARE-Spam-Status: No, hits=-6.4 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_HI, SPF_HELO_PASS, 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; Fri, 27 May 2011 19:25:28 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p4RJPRup019836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 27 May 2011 15:25:27 -0400 Received: from [127.0.0.1] (ovpn-113-23.phx2.redhat.com [10.3.113.23]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p4RJPR8M006937 for ; Fri, 27 May 2011 15:25:27 -0400 Message-ID: <4DDFFAA6.3020506@redhat.com> Date: Fri, 27 May 2011 15:25:26 -0400 From: Jason Merrill User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: gcc-patches List Subject: C++ PATCH for c++/47687 (infinite recursion with lambda returning lambda) 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 Here, deciding whether the nested lambda was dependent meant checking the enclosing function, which meant checking the function's type, which meant checking its return type, the nested lambda. I've broken this cycle by looking not at whether the enclosing function is a dependent expression, but whether it is a template. Tested x86_64-pc-linux-gnu, applying to trunk. commit 5656f70c3b34354e29de75db6dad0a0b44ef6f04 Author: Jason Merrill Date: Fri May 27 12:05:59 2011 -0400 PR c++/47687 * pt.c (dependent_type_p_r): Avoid infinite recursion. diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c index 71fe0a0..ae3d83d 100644 --- a/gcc/cp/pt.c +++ b/gcc/cp/pt.c @@ -18260,8 +18260,15 @@ dependent_type_p_r (tree type) scope = TYPE_CONTEXT (type); if (scope && TYPE_P (scope)) return dependent_type_p (scope); - else if (scope && TREE_CODE (scope) == FUNCTION_DECL) - return type_dependent_expression_p (scope); + /* Don't use type_dependent_expression_p here, as it can lead + to infinite recursion trying to determine whether a lambda + nested in a lambda is dependent (c++/47687). */ + else if (scope && TREE_CODE (scope) == FUNCTION_DECL + && DECL_LANG_SPECIFIC (scope) + && DECL_TEMPLATE_INFO (scope) + && (any_dependent_template_arguments_p + (INNERMOST_TEMPLATE_ARGS (DECL_TI_ARGS (scope))))) + return true; /* Other types are non-dependent. */ return false; diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested4.C b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested4.C new file mode 100644 index 0000000..a5bd1a2 --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested4.C @@ -0,0 +1,9 @@ +// PR c++/47687 +// { dg-options -std=c++0x } + +template struct A { }; + +auto inl = []{ return []{}; }(); +typedef decltype(inl) inlt; + +A a;