On 11/20/19 10:54 AM, David Malcolm wrote:
On Wed, 2019-11-20 at 00:38 +0100, Jakub Jelinek wrote:
Hi!
The following patch is a minimal fix to avoid
cannot convert ‘‘addr_expr’ not supported by dump_type<type error>’
to ‘X*’
and similar messages. The recently added complain_about_bad_argument
function expects a from_type argument, but conv->from isn't
necessarily a
type, it can be an expression too.
With this patch one gets error like:
cannot convert ‘const X*’ to ‘X*’
and note like
initializing argument 'this' of ‘void X::foo()’
Still, perhaps what GCC 8 and earlier used to emit might be clearer:
pr90767-1.C: In member function ‘X::operator T() const’:
pr90767-1.C:12:7: error: no matching function for call to ‘X::foo()
const’
pr90767-1.C:6:8: note: candidate: ‘void X::foo()’ <near match>
pr90767-1.C:6:8: note: passing ‘const X*’ as ‘this’ argument
discards qualifiers
There is the print_conversion_rejection function that handles the
various
cases, like this vs. other arguments, conv->from with expr type vs.
type
etc.
Though, I must say I don't understand the reasons why
complain_about_bad_argument
has been added and whether we'd want to emit there what
print_conversion_rejection prints as notes with 2 leading spaces
instead as
errors with no leading spaces.
I added complain_about_bad_argument in r264250 (aka
b78e49d1ddf1a09e16152353b41bf7c0b44d6405); the intent is to special-
case when there's a single candidate due to a bad argument, underlining
the pertinent bogus argument at the callsite, rather than having the
caret at the final close-paren of the call.
Since apparently we already have the relevant location in
conversion_info, could we achieve that by improving
print_conversion_rejection rather than using a separate
complain_about_bad_argument function?
Jason
