C++ PATCH for c++/89537 - missing location for error with non-static member fn

[Jason Merrill]

On 2/28/19 2:45 PM, Marek Polacek wrote:
> On Thu, Feb 28, 2019 at 02:33:37PM -0500, Jason Merrill wrote:
>> On 2/28/19 2:00 PM, Marek Polacek wrote:
>>> Here we issued the "invalid use of non-static member function" error with
>>> UNKNOWN_LOCATION, which merely shows "cc1plus" and no file/line.  We can
>>> greatly improve this situation with the below.
>>>
>>> The patch is IMHO trivial (though it's user-provided) to go in even at
>>> this point.
>>>
>>> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>>>
>>> 2019-02-28  Marek Polacek  <polacek@redhat.com>
>>>
>>> 	PR c++/89537 - missing location for error with non-static member fn.
>>> 	* call.c (resolve_args): Use EXPR_LOCATION.
>>> 	* typeck.c (build_class_member_access_expr): Use input_location.
>>>
>>> 	* g++.dg/diagnostic/member-fn-1.C: New test.
>>>
>>> diff --git gcc/cp/call.c gcc/cp/call.c
>>> index fb67d905acd..d9073d7c23d 100644
>>> --- gcc/cp/call.c
>>> +++ gcc/cp/call.c
>>> @@ -4246,7 +4246,7 @@ resolve_args (vec<tree, va_gc> *args, tsubst_flags_t complain)
>>>    	    error ("invalid use of void expression");
>>>    	  return NULL;
>>>    	}
>>> -      else if (invalid_nonstatic_memfn_p (arg->exp.locus, arg, complain))
>>> +      else if (invalid_nonstatic_memfn_p (EXPR_LOCATION (arg), arg, complain))
>>
>> Maybe cp_expr_loc_or_loc (arg, input_location)?
> 
> That gives a suboptimal location:
> 
>    values(p1->values) {}
>                     ^
> whereas with my fix:
> 
>    values(p1->values) {}
>           ~~~~^~~~~~
> 
>>>    	return NULL;
>>>        }
>>>      return args;
>>> diff --git gcc/cp/typeck.c gcc/cp/typeck.c
>>> index 1db9333b5ff..1bf9ad88141 100644
>>> --- gcc/cp/typeck.c
>>> +++ gcc/cp/typeck.c
>>> @@ -2562,7 +2562,8 @@ build_class_member_access_expr (cp_expr object, tree member,
>>>    	type = unknown_type_node;
>>>          /* Note that we do not convert OBJECT to the BASELINK_BINFO
>>>    	 base.  That will happen when the function is called.  */
>>> -      result = build3 (COMPONENT_REF, type, object, member, NULL_TREE);
>>> +      result = build3_loc (input_location, COMPONENT_REF, type, object, member,
>>> +			   NULL_TREE);
>>
>> Then I think this change shouldn't be needed.
> 
> The build3 call above this block also uses input_location.

The patch is OK, then.

Jason