[cfe-dev] [PATCH] New syntax and functionality for __has_attribute

[Alp Toker]

On 13/01/2014 00:38, Sean Silva wrote:
>
>
>
> On Sun, Jan 12, 2014 at 6:53 PM, Aaron Ballman <aaron at aaronballman.com 
> <mailto:aaron at aaronballman.com>> wrote:
>
>     > That's good news -- thanks for confirming.
>     >
>     > The feature detection macro itself will still need to have a
>     different name
>     > (or some other mechanism) so it can be used compatibly with
>     existing clang
>     > deployments, because _has_attribute() currently emits a parse
>     error instead
>     > of gracefully returning 0 when passed the new argument syntax:
>     >
>     > tmp/attr2.cpp:1:5: error: builtin feature check macro requires a
>     > parenthesized identifier
>     > #if __has_attribute(__attribute__((weakref)))
>     >     ^
>
>     Good catch. Unfortunately, __has_attribute is really the best
>     identifier for the macro, so I am loathe to let it go.
>
>     Due to the current design of __has_attribute, we can't get away with "
>     magic" by expanding the non-function-like form into a value that could
>     be tested. So we would really have to pick a new name if we are
>     worried about this.
>
>     Suggestions on the name are welcome.
>
>
> Ok, I'll bite:
>
> __has_attribute_written_as([[foo]])
> __has_attribute_syntax([[foo]])
> __has_attribute_spelling([[foo]])

Another possibility:

__has_any_attribute([[foo]])

The silver lining to any one of these names is that they describe the 
new semantics more clearly without overloading the existing feature macro.

With the naming and forward compatibility changes, the proposal appears 
to pass the "can we use it in LLVM Compiler.h" sanity check with flying 
colours.

As for the question of what to do with the old __has_attribute, ~400 
uses show up in an Ohloh code search and I'd be concerned to deprecate 
the present usage without strong reason.

Instead of deprecation and code churn, how about restricting and shoring 
up the old semantics to match actual usage in the wild? All uses I've 
seen on Ohloh so far appear to be checking for GNU attributes only.

It sounds like we're getting close to a plan of action.

Alp.


>
> -- Sean Silva
>
>     Regardless of the name picked, if
>     it's different from __has_attribute, we should deprecate the existing
>     usage since the proposed implementation is backwards compatible and
>     the existing __has_attribute is not forwards-compatible.
>
>     > For forward compatibility your new version should warn, rather
>     than emitting
>     > an error, upon encountering invalid attribute syntaxes that may
>     be valid in
>     > future standards or other language dialects (e.g. single-braced
>     C++/CLI []
>     > attributes should return 0, indicating "unsupported" rather than
>     triggering
>     > a parse error).
>
>     I agree, and will implement for the next round.
>
>     ~Aaron
>     _______________________________________________
>     cfe-commits mailing list
>     cfe-commits at cs.uiuc.edu <mailto:cfe-commits at cs.uiuc.edu>
>     http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>

-- 
http://www.nuanti.com
the browser experts