[cfe-dev] __PRETTY_FUNCTION__ in clang

[Mikhail Ramalho via cfe-dev]

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,


2018-02-01 17:56 GMT+00:00 Keane, Erich <erich.keane at intel.com>:

> 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.
>



-- 

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