[cfe-dev] Premature macro expansion in preprocessor?

[Richard Smith]

On Fri, Nov 9, 2012 at 2:48 PM, Chandler Carruth <chandlerc at google.com> wrote:
> On Fri, Nov 9, 2012 at 2:37 PM, Andy Gibbs <andyg1001 at hotmail.co.uk> wrote:
>> Hi,
>>
>> In going through the preprocessor code in clang, I have noted a tendancy
>> towards using Lex(Tok) over LexUnexpandedToken(Tok), for example in the
>> built-in macro implementations.
>>
>> This means, the following "works":
>>
>> #define HB __has_builtin
>> #define LP (
>> #define BT __builtin_trap
>> #define RP )
>>
>> HB LP BT RP   // expands to 1
>>
>> My question is, is this intentional, or an oversight?
>
> Without commenting about the problem you observe in full generality, I
> was talking to Doug about this the other day, and we both thought that
> it was an oversight that macro expansion took place inside of many of
> the __has_...() feature test constructs. Those should directly test
> the token provided, so that people can use them without
> __uglified__names__everywhere__ ;]
>
> __has_feature and __has_extension should *definitely* work like this.
>
> My inclination is make __has_attribute also work like this.
>
> On the other hand, I think an argument can be made that
> __has_builtin()s argument should be subject to macro expansion, as the
> builtins themselves are.
>
>
> The __has_include and other test macros that accept a string literal
> clearly aren't applicable here.
>
>
> Personally, I also find it distasteful that the feature tests are
> treated as normal function-style-macros, as I don't think it is
> reasonable to use your LP and RP macros above ...

I think the opposite. It is highly desirable that the __has_foo
builtins act exactly like function-style macros, so that this
(documented!) pattern can be used portably:

#ifndef __has_foo
#define __has_foo(x) 0
#endif