[C++] PR 85014 ("[7/8/9 Regression] internal compiler error: in lookup_base, at cp/search.c:185")

Message ID 07a88118-55bf-a1e0-08d0-9d7f0bef2fbf@oracle.com
State New
Headers show
Series
  • [C++] PR 85014 ("[7/8/9 Regression] internal compiler error: in lookup_base, at cp/search.c:185")
Related show

Commit Message

Paolo Carlini March 15, 2019, 1:28 p.m.
Hi,

another - rather long standing - error-recovery regression, where, in 
some rather special circumstances, we end up passing the FUNCTION_DECL 
representing the operator () of the lambda to maybe_dummy_object and 
obviously we almost immediately crash. Not sure how much we want to dig 
- but simply checking that context_for_name_lookup is actually returning 
a type appears to work fine, the error_mark_node then propagates back to 
cp_parser_late_parse_one_default_arg and so on. In the special 
circumstances of the testcase, context_for_name_lookup finds 
ANON_AGGR_TYPE_P set for the DECL_CONTEXT of 'b' and iterates to its 
TYPE_CONTEXT which is the FUNCTION_DECL representing the operator () of 
the lambda. This is because we just called check_tag_decl on that 
anonymous type as part of calling shadow_tag on the abstract 
declaration. Tested x86_64-linux.

Thanks, Paolo.

////////////////////
/cp
2019-03-15  Paolo Carlini  <paolo.carlini@oracle.com>

	PR c++/85014
	* semantics.c (finish_non_static_data_member): Check return value
	of context_for_name_lookup and immediately return error_mark_node
	if isn't a type.

/testsuite
2019-03-15  Paolo Carlini  <paolo.carlini@oracle.com>

	PR c++/85014
	* g++.dg/cpp0x/pr85014.C: New.

Comments

Jason Merrill March 15, 2019, 5:42 p.m. | #1
On 3/15/19 9:28 AM, Paolo Carlini wrote:
> Hi,

> 

> another - rather long standing - error-recovery regression, where, in 

> some rather special circumstances, we end up passing the FUNCTION_DECL 

> representing the operator () of the lambda to maybe_dummy_object and 

> obviously we almost immediately crash. Not sure how much we want to dig 

> - but simply checking that context_for_name_lookup is actually returning 

> a type appears to work fine, the error_mark_node then propagates back to 

> cp_parser_late_parse_one_default_arg and so on. In the special 

> circumstances of the testcase, context_for_name_lookup finds 

> ANON_AGGR_TYPE_P set for the DECL_CONTEXT of 'b' and iterates to its 

> TYPE_CONTEXT which is the FUNCTION_DECL representing the operator () of 

> the lambda. This is because we just called check_tag_decl on that 

> anonymous type as part of calling shadow_tag on the abstract 

> declaration. Tested x86_64-linux.


OK.

Jason

Patch

Index: cp/semantics.c
===================================================================
--- cp/semantics.c	(revision 269693)
+++ cp/semantics.c	(working copy)
@@ -1828,7 +1828,15 @@  finish_non_static_data_member (tree decl, tree obj
     {
       tree scope = qualifying_scope;
       if (scope == NULL_TREE)
-	scope = context_for_name_lookup (decl);
+	{
+	  scope = context_for_name_lookup (decl);
+	  if (!TYPE_P (scope))
+	    {
+	      /* Can happen during error recovery (c++/85014).  */
+	      gcc_assert (seen_error ());
+	      return error_mark_node;
+	    }
+	}
       object = maybe_dummy_object (scope, NULL);
     }
 
Index: testsuite/g++.dg/cpp0x/pr85014.C
===================================================================
--- testsuite/g++.dg/cpp0x/pr85014.C	(nonexistent)
+++ testsuite/g++.dg/cpp0x/pr85014.C	(working copy)
@@ -0,0 +1,10 @@ 
+// { dg-do compile { target c++11 } }
+// { dg-options "" }
+
+struct {
+  short a[__builtin_constant_p([] {
+    struct {
+      int b = b;
+      };  // { dg-error "abstract declarator" }
+  })];
+};  // { dg-error "abstract declarator" }