> 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. 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 [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
