Re: messages

[Joe Buck <Joe dot Buck at synopsys dot COM>]

On Mon, Apr 13, 2009 at 05:10:23PM -0700, Dave Korn wrote:
> Joe Buck wrote:
> 
> > 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.
> 
>   Hmm, I'm not a language lawyer, but isn't there already a well-ordered
> definition of more or less closely-matching in the whole C++ name resolution
> thing?  It could be confusing if our warnings operated a significantly
> different standard for what's close and what's not than that defined in the
> language spec, but in terms of doing what the user meant, we'd probably want
> to treat certain mismatches as more significant than others for diagnostic
> purposes (e.g. the common char[] vs char * when passing a const string problem).

Standards compliance is satisfied when GCC accepts, or fails to accept,
the code.  If it is not accepted, then the purpose of what we print is
to help the user diagnose and correct the problem.

So if there are 17 possible overloads (which is common for operator<<
bugs), GCC's current behavior of printing all 17 is ridiculous, and
some means needs to be chosen to create a shorter list.