On Mon, Apr 13, 2009 at 03:53:04PM -0700, Dave Korn wrote:
> Nonono; I didn't mean to impugn anything you're doing, just trying to point
> out that it's not easy. Your suggestions are all valid and good ideas, but
> before they can be usefully incorporated into the compiler, they need to be
> expressed in clearer language. It's easy for us as humans to try and infer
> the original author's intent, but much more difficult for a parser.
One place that I think it shouldn't be too difficult to improve things
is to try to prune the case where there are a large number of overloaded
possibilities, but none match. It makes no sense to report them all.
Consider
#include <iostream>
struct Foo { int bar;};
int main() {
std::cerr << Foo();
}
Try it, the result is ugly, and I often encounter this one during
development. Here we have no printing operator defined for Foo, and GCC
will happily tell us about every single operator<< declaration it knows
about, no matter how irrelevant.
One possible cleanup, in the case where there is no unique match but many
overloads, is to attempt a sort by relevance and only print the top
matches, or if every match is equally irrelevant, just say that there
are no suitable matches.
And this, of course, means we have to define relevance. There are two
cases: the first is when we fail to choose an overload because of
ambiguity; there we can just report all of the choices that are tied for
"equally good". The other case is where no overload matches. There
we could try to produce a heuristic that would "score" each alternative.
Matching some but not all of the arguments would contribute some points,
likewise if the addition or removing a const qualifier would cause a
match, that would score points. It would take some tweaking to produce
a meaningful result.
