[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