__has_attribute and pragmas

Aaron Ballman aaron at aaronballman.com
Thu Dec 4 18:47:48 PST 2014


On Thu, Dec 4, 2014 at 7:16 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> 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

Agreed (also agree with your implementation detail comment). I'll drop
that from what I produce.

Thanks!

~Aaron



More information about the cfe-commits mailing list