[cfe-dev] Premature macro expansion in preprocessor?

[Chandler Carruth]

On Fri, Nov 9, 2012 at 4:41 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> 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

... Can I have my cake and eat it too? ;]

Anyways, fine, I suppose its better to live with the silliness of
function style macros if only to provide consistency for those who end
up needing function-style-macros...