On Mon, Jan 13, 2014 at 8:20 PM, Richard Smith <[email protected]> wrote: > 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.
So are you proposing that we would have a different name for the purposes of the __has_feature macro? Eg) __has_feature(__has_attribute_syntax) is 1 for the proposed functionality, and 0 otherwise? > 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). That's true, but the example also demonstrates why it's kind of nonsensical. What do the 1, 2 represent for the purposes of __has_attribute? Can they be elided? If so, can we come up with declarative rules as to when they can be elided? Thanks! ~Aaron _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
