[cfe-commits] r162937 - in /cfe/trunk: include/clang/Parse/Parser.h lib/Lex/PPMacroExpansion.cpp lib/Parse/ParseExpr.cpp test/SemaCXX/libstdcxx_is_pod_hack.cpp

[Andy Gibbs]

On Thursday, August 30, 2012 9:04 PM, Douglas Gregor committed:
> Author: dgregor
> Date: Thu Aug 30 15:04:43 2012
> New Revision: 162937
>
> URL: http://llvm.org/viewvc/llvm-project?rev=162937&view=rev
> Log:
> Extend the "__is_pod" hack, which demotes various type trait keywords
> (__is_pod, __is_signed, etc.) to normal identifiers if they are
> encountered in certain places in the grammar where we know that prior
> versions of libstdc++ or libc++ use them, to still allow the use of
> these keywords as type traits. Fixes <rdar://problem/9836262> and PR10184.
>
> Modified:
>    cfe/trunk/include/clang/Parse/Parser.h
>    cfe/trunk/lib/Lex/PPMacroExpansion.cpp
>    cfe/trunk/lib/Parse/ParseExpr.cpp
>    cfe/trunk/test/SemaCXX/libstdcxx_is_pod_hack.cpp
>
> [...snip...]
>
> Modified: cfe/trunk/lib/Lex/PPMacroExpansion.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/PPMacroExpansion.cpp?rev=162937&r1=162936&r2=162937&view=diff
> ==============================================================================
> --- cfe/trunk/lib/Lex/PPMacroExpansion.cpp (original)
> +++ cfe/trunk/lib/Lex/PPMacroExpansion.cpp Thu Aug 30 15:04:43 2012
> @@ -719,22 +719,12 @@
>             // "struct __is_empty" parsing hack hasn't been needed in this
>             // translation unit. If it has, __is_empty reverts to a normal
>             // identifier and __has_feature(is_empty) evaluates false.
> -           .Case("is_empty",
> -                 LangOpts.CPlusPlus &&
> -                 PP.getIdentifierInfo("__is_empty")->getTokenID()
> -                                                            != 
> tok::identifier)
> +           .Case("is_empty", LangOpts.CPlusPlus)

I know this is dredging something up from the distant past, but should the 
comment re the parsing hack also be removed like it has with the __is_pod 
change below?  Reviewing the code in PPMacroExpansion, I noted that 
__has_feature(is_empty) does not behave as the comment would imply.  I 
wondered whether this was a regression that had crept in at some point?

With your agreement, I'll remove the comment as obsolete.

Thanks
Andy

>            .Case("is_enum", LangOpts.CPlusPlus)
>            .Case("is_final", LangOpts.CPlusPlus)
>            .Case("is_literal", LangOpts.CPlusPlus)
>            .Case("is_standard_layout", LangOpts.CPlusPlus)
> -           // __is_pod is available only if the horrible
> -           // "struct __is_pod" parsing hack hasn't been needed in this
> -           // translation unit. If it has, __is_pod reverts to a normal
> -           // identifier and __has_feature(is_pod) evaluates false.
> -           .Case("is_pod",
> -                 LangOpts.CPlusPlus &&
> -                 PP.getIdentifierInfo("__is_pod")->getTokenID()
> -                                                            != 
> tok::identifier)
> +           .Case("is_pod", LangOpts.CPlusPlus)
>            .Case("is_polymorphic", LangOpts.CPlusPlus)
>            .Case("is_trivial", LangOpts.CPlusPlus)
>            .Case("is_trivially_assignable", LangOpts.CPlusPlus)