On Sun, Jan 12, 2014 at 7:49 PM, Alp Toker <[email protected]> wrote: > > On 13/01/2014 00:38, Sean Silva wrote: > >> >> >> >> On Sun, Jan 12, 2014 at 6:53 PM, Aaron Ballman <[email protected] >> <mailto:[email protected]>> 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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
