Some ideas on showing overload resolution result

[GKxxUCAS]

It would be nice if C++ Insights can show overload resolution results or even more (e.g. the reason why it is the best match).

e.g. The following code shows why we should prefer nullptr to NULL:

#include <cstddef>

void foo(long);
void foo(int *);

int main() {
  foo(nullptr);
  foo(NULL);
  return 0;
}

Current C++ Insights does no change to this code. I want

#include <cstddef>

void foo(long);
void foo(int *);

int main() {
  foo(nullptr) /* void foo(int *); */;
  foo(NULL) /* void foo(long); */;
  return 0;
}

I think this is not difficult to achieve. Maybe a command line opt can be added to enable or disable it.

With respect to getting the overload set or knowing whether a call needs overload resolution:

• Maybe some facilities related to overloading can be used. I have not found a way of using them though.
• Maybe we can let the user mark the calls and the function declarations they are interested in, through comments, empty macros or command line options. (Sadly C++ double-bracket attributes cannot be customized without modifying LibTooling directly.) If the cases are limited to only a few calls and decls that are marked by the user, maybe we can just traverse the AST, recording and handling the overload information manually?

It would be awesome if moreover some explanation can be provided (e.g. Which ones are viable? What are the implicit conversion sequences and what are their ranks? Why is the selected one considered the best match?).

I have to say that the overload resolution rules are massive, and providing explanation for all cases may be impossible. Maybe we can find a subset of those rules that isn't that massive and can handle a great proportion of real-world cases? Personally I think most real-world cases aren't that tricky, and many of them are overloads against different number of arguments, against different class types, const vs non-const, const& vs &&, builtin types vs class types, integers vs floats, etc.

Looking forward to your reply.