[llvm] r278170 - Add a platform independent version of __PRETTY_FUNCTION__.

Justin Bogner via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 9 15:53:59 PDT 2016


Yep, I was going to mention that __func__ is in C++11, so it should
always be available.

In answer to your other question, I'm not actually sure that there are
any compilers that can compile LLVM and don't have either
__PRETTY_FUNCTION__ or __FUNCSIG__, but I'm not sure there aren't
either. Maybe something like xlC, or oracle's compiler? Seems best to do
a best effort here anyway.

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


More information about the llvm-commits mailing list