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

[Zachary Turner via llvm-commits]

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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160809/b3c674cb/attachment.html>