[C++ Patch] Fix three additional locations

[Paolo Carlini]

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 thus the only - brittle - way to achieve that is relying on 
input_location. That appears to work for the cases in decl.c and decl2.c 
but, as far as I can see, nothing similar can be cooked up for the 
check_methods case (we don't have the initializer at all, input_location 
doesn't make any sense). On the other hand, front-ends like clang just 
consistently use the location of the decl, that's why I decided to go 
ahead and propose a simple solution using everywhere that location.

Looks like for the time being we can't make much progress, because, in 
most of the error messages related to the initializers, thanks to 
input_location we can point to the initializers and resolving the 
inconsistency with check_methods seems tough.

Paolo.