[cfe-dev] __PRETTY_FUNCTION__ in clang

[Keane, Erich via cfe-dev]

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.

From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of Mikhail Ramalho via cfe-dev
Sent: Thursday, February 1, 2018 9:50 AM
To: Mikhail Ramalho via cfe-dev <cfe-dev at lists.llvm.org>
Subject: [cfe-dev] __PRETTY_FUNCTION__ in clang

Hi all,

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

template <typename T> struct X
{
  X() { std::cout << __PRETTY_FUNCTION__ << '\n';}
};
X<void> x;

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

In clang:
X<void>::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,

--

Mikhail Ramalho.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180201/e47ab184/attachment.html>