On Wed, Sep 5, 2018 at 11:08 AM, David Malcolm <dmalc...@redhat.com> wrote: > On Thu, 2018-08-30 at 18:18 -0400, Jason Merrill wrote: >> On Thu, Aug 23, 2018 at 2:08 PM, David Malcolm <dmalc...@redhat.com> >> wrote: >> > This is a followup to: >> > >> > "[PATCH] C++: underline param in print_conversion_rejection (more >> > PR c++/85110)" >> > https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01480.html >> > >> > to highlight the pertinent argument in a unmatched function call >> > for which there is one candidate. >> > >> > It updates the output from: >> > >> > demo.cc: In function 'int test_4(int, const char*, float)': >> > demo.cc:5:44: error: no matching function for call to >> > 's4::member_1(int&, const char*&, float&)' >> > 5 | return s4::member_1 (first, second, third); >> > | ^ >> > demo.cc:1:24: note: candidate: 'static int s4::member_1(int, const >> > char**, float)' >> > 1 | struct s4 { static int member_1 (int one, const char **two, >> > float three); }; >> > | ^~~~~~~~ >> > demo.cc:1:56: note: no known conversion for argument 2 from >> > 'const char*' to 'const char**' >> > 1 | struct s4 { static int member_1 (int one, const char **two, >> > float three); }; >> > | ~~~~~~~~~~~~~^~~ >> > >> > to: >> > >> > demo.cc: In function 'int test_4(int, const char*, float)': >> > demo.cc:5:31: error: no matching function for call to >> > 's4::member_1(int&, const char*&, float&)' >> > 5 | return s4::member_1 (first, second, third); >> > | ^~~~~~ >> >> Hmm, it seems pretty subtle to just change the highlighting when the >> message talks about the call as a whole. I think if we're going to >> focus in this way we might change the diagnostic to something like >> >> error: no known conversion for argument 2 from 'const char*' to >> 'const char**' >> note: in call to 'static int s4::member_1(int, const char**, float)' >> >> or whatever the messages are from >> convert_arguments/convert_for_initialization which already deal with >> the single-candidate case for non-member functions. >> >> Jason > > Thanks. > > Here's an updated version of the patch. > > I broke out the "no viable candidates" case in build_new_method_call_1 > into a subroutine, and added special-case handling for when there's > a single non-viable candidate where there's an argument conversion > error. I turned the error-handling from convert_for_assignment into > a subroutine, calling it from this new special-case. > > This converts: > > demo.cc: In function 'int test_4(int, const char*, float)': > demo.cc:5:44: error: no matching function for call to 's4::member_1(int&, > const char*&, float&)' > 5 | return s4::member_1 (first, second, third); > | ^ > demo.cc:1:24: note: candidate: 'static int s4::member_1(int, const char**, > float)' > 1 | struct s4 { static int member_1 (int one, const char **two, float three); > }; > | ^~~~~~~~ > demo.cc:1:56: note: no known conversion for argument 2 from 'const char*' > to 'const char**' > 1 | struct s4 { static int member_1 (int one, const char **two, float three); > }; > | ~~~~~~~~~~~~~^~~ > > to: > > demo.cc: In function 'int test_4(int, const char*, float)': > demo.cc:5:31: error: cannot convert 'const char*' to 'const char**' > 5 | return s4::member_1 (first, second, third); > | ^~~~~~ > | | > | const char* > demo.cc:1:56: note: initializing argument 2 of 'static int > s4::member_1(int, const char**, float)' > 1 | struct s4 { static int member_1 (int one, const char **two, float three); > }; > | ~~~~~~~~~~~~~^~~ > > thus highlighting the problematic argument at the callsite (and its type).
OK, thanks. > BTW, updating the test cases shows that some of our messages are worded: > "could not convert" > and sometimes: > "cannot convert" > (see e.g. g++.old-deja/g++.jason/conversion11.C which would now > have two of them side-by-side). I'm not sure that this is a problem > (maybe save for a followup? If it is an issue, it's presumably a > pre-existing one) Indeed, a pre-existing issue. I assume that we want to unify on present tense; does that sound right to you? Jason
