This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ PATCH] Fix weird addr_expr not supported by dump_expr messages (PR c++/90767)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: David Malcolm <dmalcolm at redhat dot com>
- Cc: Jason Merrill <jason at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 20 Nov 2019 12:04:59 +0100
- Subject: Re: [C++ PATCH] Fix weird addr_expr not supported by dump_expr messages (PR c++/90767)
- References: <20191119233814.GO4650@tucnak> <6945f1935582def605cf1726f2d078cac757e4d2.camel@redhat.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Nov 20, 2019 at 05:54:48AM -0500, David Malcolm wrote:
> 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.
>
> But it looks like I forgot about the "this" case. Does it make more
> sense for pr90767-1.C to reject the special-casing if conv->n_arg is -1
> for the "this"? (either in
> complain_about_no_candidates_for_method_call, or in
> maybe_get_bad_conversion_for_unmatched_call); perhaps like this:
I don't know. Either something like that, or handle those cases in
complain_about_bad_argument specially too.
Note, print_conversion_rejection apparently has special cases for
n_arg == -1 (TYPE_P conv->from vs. non-TYPE_P)
!TYPE_P conv->from
n_arg == -2
the rest
I really don't know what exactly they mean, appart from n_arg == -1
being this, n_arg seems to be return value, but dunno when that triggers,
and it is unclear what TYPE_P conv->from vs. non-TYPE_P means.
Jakub