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

[Aaron Ballman]

On Sun, Jan 12, 2014 at 7:49 PM, Alp Toker <alp at nuanti.com> wrote:
>
> 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.

That's how we use it, and one of Richard's suggestions on the PR as
well, so I would be fine with that.

The deprecation I was speaking of was of the more silent variety --
updating the documentation to mention that the new syntax is
preferred. Not the barking loud variety where it warns on usage in
code.

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

Agreed!

~Aaron