<div dir="ltr">How does this look?<div><br></div><div><div>#if defined(_MSC_VER)</div><div>#define LLVM_PRETTY_FUNCTION __FUNCSIG__</div><div>#elif defined(__GNUC__) || defined(__clang__)</div><div>#define LLVM_PRETTY_FUNCTION __PRETTY_FUNCTION__</div><div>#else </div><div>#define LLVM_PRETTY_FUNCTION __func__</div><div>#endif</div></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 9, 2016 at 3:54 PM Justin Bogner <<a href="mailto:mail@justinbogner.com">mail@justinbogner.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yep, I was going to mention that __func__ is in C++11, so it should<br>
always be available.<br>
<br>
In answer to your other question, I'm not actually sure that there are<br>
any compilers that can compile LLVM and don't have either<br>
__PRETTY_FUNCTION__ or __FUNCSIG__, but I'm not sure there aren't<br>
either. Maybe something like xlC, or oracle's compiler? Seems best to do<br>
a best effort here anyway.<br>
<br>
Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> writes:<br>
> How about<br>
><br>
> #else<br>
> #define LLVM_PRETTY_FUNCTION __func__<br>
> #endif<br>
><br>
> which is present in C99 and C++11?<br>
><br>
> On Tue, Aug 9, 2016 at 3:23 PM Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
><br>
>> I am using this indeed for logging in LLDB, so getTypeName() won't work.<br>
>> LLDB is using __PRETTY_FUNCTION__ and then for windows there is a line that<br>
>> says #define __PRETTY_FUNCTION __FUNCSIG__, but then non-Windows users have<br>
>> to remember to include an LLDB specific, windows-specific header which is<br>
>> frequently missed causing compiler breaks. So llvm/Compiler.h seems like a<br>
>> logical place to put this. A warning seems reasonable.<br>
>><br>
>> The only user of this at the moment will be LLDB, and either<br>
>> __PRETTY_FUNCTION__ or __FUNCSIG__ has always worked on all compilers that<br>
>> LLDB supports, so nothing should break.<br>
>><br>
>> Do you know offhand which compilers support neither, and what is the<br>
>> appropriate thing to use in those cases? getTypeName() seems to indicate<br>
>> that there may not be an equivalent, or at the very least that if there is<br>
>> an "equivalent", it's not very similar.<br>
>><br>
>> On Tue, Aug 9, 2016 at 3:19 PM Justin Bogner <<a href="mailto:mail@justinbogner.com" target="_blank">mail@justinbogner.com</a>><br>
>> wrote:<br>
>><br>
>>> Zachary Turner via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>> writes:<br>
>>> > Author: zturner<br>
>>> > Date: Tue Aug 9 17:03:45 2016<br>
>>> > New Revision: 278170<br>
>>> ><br>
>>> > URL: <a href="http://llvm.org/viewvc/llvm-project?rev=278170&view=rev" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project?rev=278170&view=rev</a><br>
>>> > Log:<br>
>>> > Add a platform independent version of __PRETTY_FUNCTION__.<br>
>>> ><br>
>>> > MSVC doesn't have this, it only has __FUNCSIG__. So this adds<br>
>>> > a new macro called LLVM_PRETTY_FUNCTION which evaluates to the<br>
>>> > right thing on any platform.<br>
>>><br>
>>> Depending what you're planning on using this for, you might be better off<br>
>>> using llvm::getTypeName (include/llvm/Support/TypeName.h). See also the<br>
>>> commit that added getTypeName for a number of caveats about trying to do<br>
>>> this portably.<br>
>>><br>
>>> Finally, this at the very least needs some big warnings about the fact<br>
>>> that it isn't portable at all and is only suitable for things like<br>
>>> logging. It also probably needs a third case for compilers that support<br>
>>> neither FUNCSIG nor PRETTY_FUNCTION.<br>
>>><br>
>>> > Modified:<br>
>>> > llvm/trunk/include/llvm/Support/Compiler.h<br>
>>> ><br>
>>> > Modified: llvm/trunk/include/llvm/Support/Compiler.h<br>
>>> > URL:<br>
>>> ><br>
>>> <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Support/Compiler.h?rev=278170&r1=278169&r2=278170&view=diff" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Support/Compiler.h?rev=278170&r1=278169&r2=278170&view=diff</a><br>
>>> ><br>
>>> ==============================================================================<br>
>>> > --- llvm/trunk/include/llvm/Support/Compiler.h (original)<br>
>>> > +++ llvm/trunk/include/llvm/Support/Compiler.h Tue Aug 9 17:03:45 2016<br>
>>> > @@ -453,6 +453,14 @@ void AnnotateIgnoreWritesEnd(const char<br>
>>> > #define LLVM_DUMP_METHOD LLVM_ATTRIBUTE_NOINLINE<br>
>>> > #endif<br>
>>> ><br>
>>> > +/// \brief Gets a user-friendly looking function signature for the<br>
>>> current scope<br>
>>> > +/// using the best available method on each platform.<br>
>>> > +#if defined(LLVM_ON_WIN32)<br>
>>> > +#define LLVM_PRETTY_FUNCTION __FUNCSIG__<br>
>>> > +#else<br>
>>> > +#define LLVM_PRETTY_FUNCTION __PRETTY_FUNCTION__<br>
>>> > +#endif<br>
>>> > +<br>
>>> > /// \macro LLVM_THREAD_LOCAL<br>
>>> > /// \brief A thread-local storage specifier which can be used with<br>
>>> globals,<br>
>>> > /// extern globals, and static globals.<br>
>>> ><br>
>>> ><br>
>>> > _______________________________________________<br>
>>> > llvm-commits mailing list<br>
>>> > <a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
>>> > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
>>><br>
>><br>
</blockquote></div>