__PRETTY_FUNCTION__ in clang

Hi all,

I recently noticed that clang and gcc print PRETTY_FUNCTION in different formats, e.g.:

template struct X
{
X() { std::cout << PRETTY_FUNCTION << ‘\n’;}
};
X x;

In gcc:
X::X() [with T = void]

In clang:
X::X() [T = void]

I only found a discussion about it from 2011, that added the template args to the output:

http://clang-developers.42468.n3.nabble.com/clang-and-gcc-implement-PRETTY-FUNCTION-differently-td3550386.html

I also created a patch that implements the gcc format, but broke all the diagnostic tests, because it needs the instantiated name to report warning/errors (which is correct in my opinion).

One solution would be adding a new attribute in PrintingPolicy to handle the case where we want to print these predefined expressions, then enabling it in PredefinedExpr::ComputeName.

Is there any interest in the community to match gcc’s output? There are some valid points in the previous thread.

Thank you,

This is actually something I’ve talked about quite a bit lately internally. If this were a few years ago before we implemented PRETTY_FUNCTION, I definitely would have been in the camp of matching GCC’s behavior.

However, my current opinion (which is only my own), is that we shouldn’t mess with it. There are a couple of libraries that depend on the format to be as it is. There is a boost library that slips my mind at the moment that does a ton of template magic based on the format of PRETTY_FUNCTION that would be broken and have to be conditionalized. I would fear breaking them again.

I see. A quick look in the boost’s source code shows that it’s used mainly for diagnostics, and defaults to func.

However, it’s also used in CTTI and hanna, which might be a problem.

I can contact them and ask if the change will break the lib. How about that?

It wouldn’t fix problems with for other libraries that we don’t know about though.

Thank you,