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.

[andreasfertig]

Hello @GKxxUCAS,

thank you for bringing up this idea. I think the main question is what we want to achieve.

You're right, acquiring the overload information isn't hard. I have a local branch for a while now doing that. The transformation of your example looks like this:

#include <cstddef>

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

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

Your idea about showing why an overload was picked, while very interesting, is way overboard, I think. I don't think Clang gives away this information, which means C++ Insights has to replicate what Clang does. At least, I don't want to maintain such a thing or implement it. Here is one of the starting points: https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaLookup.cpp#L2186 in case you want to take a closer look.

Marking the functions, somebody wants the overload information for is an interesting idea. On the other hand, if one already knows the function of interest, the code could be reduced to that, potentially, a single call.

The next issue is the representation. In your example, we have only two overloads, but what if there are 8? What if the call in question is part of another call or used as a condition inside, say, an if statement? Currently, a transformation would result in this:

  if(/* bool Test(int) USED */
  /* bool Test(char) */
  /* bool Test(double) */
  /* bool Test(float) */
  Test(3) && /* bool Test(int) USED */
  /* bool Test(char) */
  /* bool Test(double) */
  /* bool Test(float) */
  Test(static_cast<int>(true))) {
  }

A more compact version could look like this:

  if(/* bool Test(int) USED
     bool Test(char)
     bool Test(double)
     bool Test(float) */
  Test(3) && /* bool Test(int) USED
     bool Test(char)
     bool Test(double)
     bool Test(float) */
  Test(static_cast<int>(true))) {
  }

I don't know if this way would break anything.

What do you think and why/for what did you come up with the initial idea?

Andreas