On Sun, Jan 12, 2014 at 4:49 PM, Aaron Ballman <[email protected]>wrote:
> On Sun, Jan 12, 2014 at 7:38 PM, Sean Silva <[email protected]> wrote: > > > > > > > > On Sun, Jan 12, 2014 at 6:53 PM, Aaron Ballman <[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]]) > > I kind of like __has_attribute_syntax, truth be told. Have we given up on using the name __has_attribute too soon? Users of the new syntax could write: // Probably already in project's porting header #ifndef __has_feature #define __has_feature(x) 0 #endif #if __has_feature(__has_attribute_syntax) #define MY_HAS_ATTRIBUTE(...) __has_attribute(__VA_ARGS__) #else #define MY_HAS_ATTRIBUTE(...) 0 #endif If it's given a different name, they instead would write something like: #ifdef __has_attribute_syntax #define MY_HAS_ATTRIBUTE(...) __has_attribute_syntax(__VA_ARGS__) #else #define MY_HAS_ATTRIBUTE(...) 0 #endif So I don't think the change-in-syntax argument holds water. Also, supporting arguments in the attributes is useful in some cases -- it's not true that they don't make sense in a feature-checking facility. For instance: __has_attribute( __attribute__((format)) ) ... doesn't tell me whether __attribute__((format, gnu_scanf, 1, 2) will work (and I'd expect that the format attribute will gain additional archetypes in future).
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
