[PATCH] D17149: Consolidate and improve the handling of built-in feature-like macros

[Andy Gibbs via cfe-commits]

AndyG added a comment.

To be honest, the simple answer is because it was just as easy to do with nesting as without (the code would still need to track the appearance of left and right parentheses in order to correctly parse to the closing right-parenthesis of the macro invocation in any case).

And since the work has to be done anyway, it seemed reasonable to allow it.  My other thought was that when people write wrapper macros, they often (indeed idiomatically) wrap their parameters in an extra set of parentheses before passing down to the next level.  This would therefore handle this use-case.

While it may not technically be part of the specification, neither does it break it, and in the 99% most common cases the extra functionality will not come into play.

The motivation of the patch was to ensure a more robust parsing of these feature-like macros -- that and fixing __is_identifier which was fundamentally broken and where I originally started.

If you really disagree with this extension of the rules noted in your comment, I can work a logic that errors on the presence of embedded parentheses, but IMHO I think it preferable to keep it as is :o)


http://reviews.llvm.org/D17149