[cfe-dev] [PATCH] New syntax and functionality for __has_attribute

[Richard Smith]

On Sun, Jan 12, 2014 at 4:49 PM, Aaron Ballman <aaron at aaronballman.com>wrote:

> On Sun, Jan 12, 2014 at 7:38 PM, Sean Silva <silvas at purdue.edu> wrote:
> >
> >
> >
> > On Sun, Jan 12, 2014 at 6:53 PM, Aaron Ballman <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:
> >
> > __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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140113/2674bb2b/attachment.html>