http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45329
--- Comment #3 from Wolfgang Bangerth <bangerth at gmail dot com> 2010-11-18
02:42:01 UTC ---
(In reply to comment #2)
> > In either case, assuming that a sufficient number of arguments are
> > involved and if they are all templates of the kind
> > std::vector<std::vector<T>>
> > (with all the defaulted template arguments) it becomes essentially
> > impossible
> > to see easily why the call failed.
>
> Testcase?
....................
#include <vector>
void f(int, std::vector<int> &);
void f(char, std::vector<int> &);
void bar()
{
const std::vector<int> v;
f(2,v);
}
.....................
x.cc: In function 'void bar()':
x.cc:8:8: error: no matching function for call to 'f(int, const
std::vector<int>&)'
x.cc:2:6: note: candidates are: void f(int, std::vector<int>&)
x.cc:3:6: note: void f(char, std::vector<int>&)
Previous versions of gcc printed not just std::vector<int> but
the whole std::vector<int,std::allocator<...>> thing.
> I think the lack of note would be the difficult part. I don't think we have
> diagnostics without prefix.
Sorry, I misremembered. All lines have 'note', but only the first has
'candidates are'. Either way, the following ones are indented which I think
makes it more readable.
> Even if such diagnostic were implemented "note:" is a translated string, so
> the
> indentation has to be relative to it.
But is it currently? (I.e. with the "candidates are:" string that is omitted in
following lines?)
> I don't see why removing the "notes: " adds/removes blocks, since it is the
> same prefix every line. But I like the idea of using a "reason:" prefix, why
> not a "candidate:" prefix also?
I don't care how it's done but if you've stared long enough at template-laden
error messages involving half a dozen function arguments of half a dozen
candidate functions, you'd really appreciate some substructuring of the list.
> But personally, I would prefer everything in the same line:
>
> pr45329.C:26:7: error: no matching function for call to 'foo(int&)'
> pr45329.C:7:5: note: candidate 'int foo(int, int)' expects 2 arguments, 1
> provided
> pr45329.C:19:5: note: candidate 'int foo(const S&)': no known conversion for
> argument 1 from 'int'
>
> I think also that this latest version would require fewer testsuite changes.
That would work for me as well. I think the testsuite argument is mistaken,
though: the goal should be to produce quality diagnostics, not to minimize the
number of changes in the testsuite.
Best
W.
