[cfe-dev] Premature macro expansion in preprocessor?

[Chandler Carruth]

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 wonder if it would
make more sense to define the feature tests as special tokens in the
preprocessor much like defined().