[compiler-rt] r201916 - Revert "Replace __FUNCTION__ with __func__, the latter being standard C99/C++11."

[Richard Smith]

On Sat, Feb 22, 2014 at 1:33 PM, Joerg Sonnenberger <joerg at britannica.bec.de
> wrote:

> On Fri, Feb 21, 2014 at 05:48:50PM -0800, Reid Kleckner wrote:
> > On Fri, Feb 21, 2014 at 5:03 PM, Joerg Sonnenberger <
> joerg at britannica.bec.de
> > > wrote:
> >
> > > On Sat, Feb 22, 2014 at 12:37:46AM -0000, Reid Kleckner wrote:
> > > > Author: rnk
> > > > Date: Fri Feb 21 18:37:45 2014
> > > > New Revision: 201916
> > > >
> > > > URL: http://llvm.org/viewvc/llvm-project?rev=201916&view=rev
> > > > Log:
> > > > Revert "Replace __FUNCTION__ with __func__, the latter being standard
> > > C99/C++11."
> > > >
> > > > This reverts commit r201910.
> > > >
> > > > While __func__ may be standard in C++11, it was only recently added
> to
> > > > MSVC in 2013 CTP, and LLVM supports MSVC 2012.  __FUNCTION__ may not
> be
> > > > standard, but it's *very* portable.
> > >
> > > In that case it should be a local __func__=__FUNCTION__ define.
> > >
> >
> > Why?  __FUNCTION__ is incredibly portable.  I don't know of any compiler
> > that doesn't support it.  Adding a new macro in a header or on the
> command
> > line seems like more hassle than it's worth.
>
> It is not standard. It has strange properties. The only reason why it is
> still used is a compiler that doesn't even support a 15 year old
> standard. Clearly, the burden should be in the build system for that
> compiler and nowhere else. So please, revert this and implement a fix
> for the broken Microsoft compiler instead.


I don't think this is clear at all. This feature is not in C++98, and we're
not allowing C++11 features yet. Even when we do, we only intend to allow
C++11 features that are supported by all of our supported compilers, and
this is not such a feature. Why should this be treated as a special case?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140222/1c0bd0aa/attachment.html>