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.
