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

[Justin Bogner via llvm-commits]

LGTM. Do note that this will do __FUNCSIG__ behaviour for
clang-on-windows. This seems fine.

Zachary Turner <zturner at google.com> writes:
> How does this look?
>
> #if defined(_MSC_VER)
> #define LLVM_PRETTY_FUNCTION __FUNCSIG__
> #elif defined(__GNUC__) || defined(__clang__)
> #define LLVM_PRETTY_FUNCTION __PRETTY_FUNCTION__
> #else
> #define LLVM_PRETTY_FUNCTION __func__
> #endif
>
>
> On Tue, Aug 9, 2016 at 3:54 PM Justin Bogner <mail at justinbogner.com> wrote:
>
>> 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
>> >>>
>> >>
>>