[cfe-commits] [PATCH] Limit the number of overload candidates printed (issue1591041)

[Chris Lattner]

On Jun 8, 2010, at 1:52 PM, Douglas Gregor wrote:

>> 
>> >
>> > Unless we can be fairly sure that the "right" operator<< is in those first 4 overload candidates, I don't think this is a good idea. Unlike with suppressing inner template/macro instantiation histories, this change is likely to suppress important information.
>> >
>> 
>> I agree that it will sometimes suppress important information. That's why I added the -fshow-all-overloads flag so the user can get it back if they need it.
> 
> Sure, and it's good to have -fshow-all-overloads for any kind of pruning. My concern is that if the pruning is not good by default, we'll end up causing more harm than good: the user will have to bounce between -fshow-all-overloads and non-fshow-all-overloads whenever they hit problems. That's worse than having a longer diagnostic chain in the first place.

I strongly agree with Doug here.  IMO, requiring people to go stare at their code *is ok*, but requiring them to go twiddle a command line option is gross (realistically it's a non-starter for GUI users for example).

I think there are at least three important cases here:

1. The candidate list is short enough that all can be listed (e.g. <= 8), just list them.

2. The candidate list is long, but some of the matches are much better than most of them.  In this case, I'd like to see something like this:

error: no match for 'foo'
note: candidate 1 (best one)
note: candidate ...
note: candidate 6 (a close one but not right)
note: 42 candidates elided because they were way too wrong

When getting this sort of diagnostic, I'm okay with forcing the user to go stare at their code again.  With 48 candidates, I agree that listing them is useless.

3. The candidate list is long and there is no "particularly close" match.  This is the operator<< case with ostream when you forget to include the header that defines the right << for example.  Here there is very little point in listing *any* of the candidates.  I think that this should go into a super-concise mode that could even list multiple candidates per line or something with no location information.

It may also be useful to distinguish overloading cases where all the candidates are members a class vs they include free functions.  In any case, I am really opposed to a hard truncation at a fixed candidate limit.

-Chris