[C++ Patch] Fix three additional locations

Jason Merrill jason@redhat.com
Fri Jan 11 22:24:00 GMT 2019


On 1/11/19 4:56 PM, Paolo Carlini wrote:
> Hi,
> 
> On 11/01/19 22:22, Jason Merrill wrote:
>> On 1/11/19 4:13 PM, Paolo Carlini wrote:
>>> Hi,
>>>
>>> On 11/01/19 19:58, Jason Merrill wrote:
>>>> On 1/10/19 9:24 AM, Paolo Carlini wrote:
>>>>> Hi again,
>>>>>
>>>>> this one is also matter of consistency with, say, the precise 
>>>>> location that we use for the error message at the beginning of 
>>>>> check_methods. Indeed, the sequence of error messages of 
>>>>> g++.dg/inherit/pure1.C reflect that. Tested x86_64-linux.
>>>>>
>>>>> Thanks, Paolo.
>>>>>
>>>>> PS: minor issues anyway, but I'm almost done with these low hanging 
>>>>> fruits which I'm proposing to fix for 9 too....
>>>>
>>>> Hmm, wouldn't it be preferable to use the location of the 
>>>> initializer when the initializer is the problem?
>>>
>>> I see what you mean and indeed yesterday I gave that some thought. In 
>>> practice, we have the usual issue that currently constants don't have 
>>> a location
>>
>> They do now in a lot more cases, with location wrappers.  If not, we 
>> could fall back on the decl location with EXPR_LOC_OR_LOC.
> 
> Yes. And that's what we are in fact already doing in all the other uses 
> of cp_expr_loc_or_loc in decl.c. Seems a good solution to me too. I'm 
> finishing testing the below.

OK.

Jason



More information about the Gcc-patches mailing list