[llvm-commits] [llvm] r172156 - /llvm/trunk/include/llvm/Support/Compiler.h

[Joerg Sonnenberger]

On Fri, Jan 11, 2013 at 08:03:22PM +0200, Dmitri Gribenko wrote:
> On Fri, Jan 11, 2013 at 4:50 PM, Joerg Sonnenberger
> <joerg at britannica.bec.de> wrote:
> > On Fri, Jan 11, 2013 at 02:32:41PM +0200, Dmitri Gribenko wrote:
> >> On Fri, Jan 11, 2013 at 4:59 AM, Joerg Sonnenberger
> >> <joerg at britannica.bec.de> wrote:
> >> > On Fri, Jan 11, 2013 at 04:37:34AM +0200, Dmitri Gribenko wrote:
> >> >> On Fri, Jan 11, 2013 at 4:33 AM, Joerg Sonnenberger
> >> >> <joerg at britannica.bec.de> wrote:
> >> >> > On Fri, Jan 11, 2013 at 01:13:51AM -0000, Dmitri Gribenko wrote:
> >> >> >> Author: gribozavr
> >> >> >> Date: Thu Jan 10 19:13:51 2013
> >> >> >> New Revision: 172156
> >> >> >>
> >> >> >> URL: http://llvm.org/viewvc/llvm-project?rev=172156&view=rev
> >> >> >> Log:
> >> >> >> Add a new portability macro LLVM_FUNCTION_NAME, that expands to __func__, if
> >> >> >> supported.
> >> >> >>
> >> >> >> Modified:
> >> >> >>     llvm/trunk/include/llvm/Support/Compiler.h
> >> >> >
> >> >> > Why don't you add
> >> >> >
> >> >> > #if defined(_MSC_VER)
> >> >> > #define __func__ __FUNCTION__
> >> >> > #endif
> >> >> >
> >> >> > to config.h?
> >> >>
> >> >> Because __func__ should be defined as:
> >> >>
> >> >> static const char __func__[] = "function-name";
> >> >>
> >> >> Replacements available in other compilers might behave in a different
> >> >> way, thus we need a different name to avoid confusion.
> >> >
> >> > Eh, no. The main point is that you can't use __func__ in ways that
> >> > expect string merging, so "foo" __func__ "bar" doesn't work unlike e.g.
> >> > GCC's __FUNCTION__. __func__ can always be replaced by "" with minimal
> >> > lose of functionality.
> >>
> >> I don't see how this contradicts what I said: available replacements
> >> might have different behavior.
> >>
> >> Anyway, #define __func__ <anything> is UB since name __func__ is reserved.
> >
> > Now you are silly. Yes, __func__ is a reserved macro name in C99. Point
> > is that Microsoft does not implement C99, so it is not reserved in their
> > dialect either.
> 
> __func__ is still reserved because it contains two underscores -- all
> identifiers that match the regex /.*__.*/ are reserved in C++
> ([global.names] p1).

Again, what are you trying to do? If you want to emulate __func__ on
MSVC, just do the above. There is no reason to abstract this for the
sake of a single compiler. It is unnecessary churn.

Joerg