__has_attribute and pragmas

Richard Smith richard at metafoo.co.uk
Thu Dec 4 16:16:38 PST 2014


On Thu, Dec 4, 2014 at 7:22 AM, Aaron Ballman <aaron at aaronballman.com>
wrote:

> Ping
>
> On Mon, Nov 24, 2014 at 10:02 AM, Aaron Ballman <aaron at aaronballman.com>
> wrote:
> > On Thu, Nov 20, 2014 at 7:22 PM, Richard Smith <richard at metafoo.co.uk>
> wrote:
> >> On Thu, Nov 20, 2014 at 3:48 PM, Aaron Ballman <aaron at aaronballman.com>
> >> wrote:
> >>>
> >>> On Thu, Nov 20, 2014 at 6:27 PM, Richard Smith <richard at metafoo.co.uk>
> >>> wrote:
> >>> > On Thu, Nov 20, 2014 at 1:38 PM, Aaron Ballman <
> aaron at aaronballman.com>
> >>> > wrote:
> >>> >>
> >>> >> The __has_attribute implementation does not pay attention to the
> >>> >> syntax supported by attributes -- instead, it looks to see whether
> an
> >>> >> attribute is generally known with that spelling. Since pragmas can
> now
> >>> >> be spelled as attributes, this means __has_attribute(loop) returns
> >>> >> true because of the #pragma loop functionality. Same for unroll.
> >>> >>
> >>> >> Should __has_attribute ignore attributes spelled with a #pragma
> >>> >> spelling?
> >>> >
> >>> >
> >>> > I would go further: __has_attribute should probably only look for
> >>> > GNU-syntax
> >>> > attributes. We have __has_cpp_attribute for C++-syntax attributes
> now,
> >>> > and I
> >>> > don't think anyone is (yet) using this for __declspec, so now seems
> like
> >>> > a
> >>> > good time to make this change.
> >>>
> >>> A long, long while back, we discussed having a way to determine
> >>> attributes by syntax, because that's sometimes important, as well as a
> >>> general query mechanism.
> >>>
> >>> How about adding:
> >>>
> >>> __has_declspec_attribute
> >>> __has_keyword_attribute
> >>> __has_gnu_attribute
> >>>
> >>> and leaving __has_attribute generic across syntaxes?
> >>>
> >>> This also reduces the chances of breaking code by allowing the
> >>> __has_attribute syntax to continue to work as it always has.
> >>
> >>
> >> Back when we only had GNU attributes, that's all it detected. I'm not
> >> convinced that people are actually using it for anything else,
> >
> > I believe I've seen some code using it for __declspec attributes.
> > IIRC, we may have run into this with MinGW, which implements
> > __declspec as a macro, replaced by __attribute__.
> >
> >> and I think
> >> it would be surprising if it said an attribute was supported but that
> >> attribute didn't work with GNU syntax. A generic-across-syntaxes
> >> __has_attribute is basically useless.
> >
> > The more I think about cross-syntax attribute checking, the more I
> > agree it's useless.
> >
> > I still think it would make sense to add the various forms of this,
> > and I definitely think that pragmas should be excluded from
> > __has_attribute.
> >
> > How does this sound as a path forward:
> >
> > * Change __has_attribute to only support GNU-style attributes. This
> > has the potential to break code, so this will require careful watching
> > of the lists.
> > * Add __has_declspec_attribute & __has_keyword_attribute, that only
> > apply to __declspecs and keywords.
>

Sounds good to me, except perhaps for the __has_keyword_attribute part. We
already provide that functionality through __is_identifier, and it's not
completely clear to me that we want both mechanisms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141204/4cb57498/attachment.html>


More information about the cfe-commits mailing list