On 10/11/2018 06:04 AM, Joseph Myers wrote:
On Thu, 11 Oct 2018, Martin Sebor wrote:
The attached patch introduces a built-in function called
__builtin_has_attribute that makes some of this possible.
See the documentation and tests for details.
I see nothing in the documentation about handling of equivalent forms of
an attribute - for example, specifying __aligned__ in the attribute but
aligned in __builtin_has_attribute, or vice versa. I'd expect that to be
documented to work (both of those should return true), with associated
tests. (And likewise the semantics should allow for a format attribute
using printf in one place and __printf__ in the other, for example, or the
same constant argument represented with different expressions.)
Yes, it occurred to me belatedly that I should add a test for those
as well. I can also mention it in the documentation, although I'd
have thought it would be implicit in how attributes work in general.
(Or are there some differences between the underscored forms and
the one without it)?
What are the semantics of __builtin_has_attribute for attributes that
can't be tested for? (E.g. the mode attribute, which ends up resulting in
some existing type with the required mode being used, so there's nothing
to indicate the attribute was originally used to declare things.)
With a few exceptions (like aligned) the built-in returns false
for attributes that aren't attached to a node. I haven't exercised
nearly all the attributes yet, and this one could very well be among
those that aren't and perhaps can't be handled. I suspect some
target attributes might be in the same group. If there's no way
to tell it should probably be documented as a limitation of
the function, maybe also under the attribute itself that can't
be detected. Alternatively, the built-in return type could be
changed to a tri-state: "don't know," false, true. Can you
think of a better solution?
Martin
