[cfe-dev] [PATCH] New syntax and functionality for __has_attribute
aaron at aaronballman.com
Sun Jan 12 16:52:09 PST 2014
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:
> Another possibility:
> 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
> 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
> It sounds like we're getting close to a plan of action.
More information about the cfe-dev