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

John McCall rjmccall at apple.com
Tue Jun 8 11:10:11 PDT 2010


On Jun 8, 2010, at 7:49 AM, Douglas Gregor wrote:

> 
> On Jun 7, 2010, at 6:03 PM, jyasskin at gmail.com wrote:
> 
>> Reviewers: cfe-commits_cs.uiuc.edu,
>> 
>> Message:
>> Please take a look. If you prefer reviewing diffs, they're behind the
>> "Download raw patch set" link.
>> 
>> Description:
>> When there are lots of operator<<s, clang produces significantly worse
>> diagnostics than gcc, simply because of the size of the output. This
>> patch limits clang to 4 overload candidates, with the ability to show
>> the rest by passing -fshow-all-overloads, as a first cut. We'll want to
>> refine that later as examples of bad behavior come up.
> 
> 
> 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.

One idea would be to cut off after a substantial drop in match quality.  We'd need a lot of extra work on the match-quality comparator, though;  for example, it currently categorically ranks functions with arity mismatches after functions  with matching argument counts.  Obviously that's bad if the user just forgot an argument.

Of course, this is only likely to come up for builtin operators and things like std::swap, in which case arity mismatches won't help us.  Maybe a simple heuristic like "arity matches that would require a user-defined conversion should go last" would be sufficient.

John.



More information about the cfe-commits mailing list