AST matcher for C++11 [[attributes]]

Hi everyone,
I am not sure of this is the right list. I have an issue with clang-tidy’s predefined AST Matchers. The documentation for using clang-tidy (http://clang.llvm.org/extra/clang-tidy/) suggests that one should first try to use of predefined matchers listed in http://clang.llvm.org/docs/LibASTMatchersReference.html.

But there is no matcher for C++11 [[attributes]]. There is matcher hasAttr, but it only works for predefined GCC attribute((s)). Now, I quess, I will have to write my own matcher, but don’t you think it would be useful to have a ready-to-use matcher for c++11 [[attributes]] ?

I need them to implement checks with fewer false positives. For instance one of the checks is clang-tidy is “warn upon converting constructors”, which is not an ideal, because sometimes I do want to implement a conversion. Instead, I would like to provide an alternative: “warn upon converting constructors not annotated as converting”. But I cannot do that easily today.

Is there any reason that such matcher should not be included in the predefined AST matchers?

Regards,
&rzej;

Hi everyone,
I am not sure of this is the right list. I have an issue with clang-tidy's
predefined AST Matchers. The documentation for using clang-tidy
(http://clang.llvm.org/extra/clang-tidy/) suggests that one should first try
to use of predefined matchers listed in
http://clang.llvm.org/docs/LibASTMatchersReference.html.

But there is no matcher for C++11 [[attributes]]. There is matcher hasAttr,
but it only works for predefined GCC __attribute__((s)).

The hasAttr() matcher works for all attributes based on the Attr::Kind
enumeration. This will not distinguish between different spellings of
the same attribute, but that should (hopefully) be largely irrelevant.
So this matcher should do what you need already.

~Aaron

Aaron, thanks for the reply. However it seams I phrased my question
incorrectly. I would like to check the existence of my own unique
attribute, say [[ab::cd::my_attribute]]. It is not in the list of any known
attributes. hasAttr() appears to only detect the known attributes that are
already listed in the long attribute enum. But will not see a new attribute.

So my question is, in clang-tidy is it possible to inspect custom
attributes, like [[ab::cd::my_attribute]] ?

Regards,
&rzej;

> Hi everyone,
> I am not sure of this is the right list. I have an issue with
> clang-tidy's
> predefined AST Matchers. The documentation for using clang-tidy
> (http://clang.llvm.org/extra/clang-tidy/) suggests that one should first
> try
> to use of predefined matchers listed in
> http://clang.llvm.org/docs/LibASTMatchersReference.html.
>
> But there is no matcher for C++11 [[attributes]]. There is matcher
> hasAttr,
> but it only works for predefined GCC __attribute__((s)).

The hasAttr() matcher works for all attributes based on the Attr::Kind
enumeration. This will not distinguish between different spellings of
the same attribute, but that should (hopefully) be largely irrelevant.
So this matcher should do what you need already.

Aaron, thanks for the reply. However it seams I phrased my question
incorrectly. I would like to check the existence of my own unique attribute,
say [[ab::cd::my_attribute]]. It is not in the list of any known attributes.
hasAttr() appears to only detect the known attributes that are already
listed in the long attribute enum. But will not see a new attribute.

So my question is, in clang-tidy is it possible to inspect custom
attributes, like [[ab::cd::my_attribute]] ?

If your custom attribute is implemented by adding the attribute to
Attr.td, then it should work fine (depending on your attribute
definition). The list of known attributes used by hasAttr() is
automatically generated from the attributes listed in Attr.td, and the
only attributes that don't get enumerated are ones which do not have
an AST node associated with them.

If your attribute is not added to Attr.td, then you are correct,
clang-tidy has no knowledge of it.

~Aaron

It might be useful to add a facility to Clang's AST to hold on to
unrecognized attributes (and to have an AST node type for that). Not every
application wants to recompile the guts of Clang just to handle users'
attributes, and might not be able to if it wants to handle attributes in
some generic way (so that the users aren't the people who are building the
tools).

-- James

>
>
>>
>> > Hi everyone,
>> > I am not sure of this is the right list. I have an issue with
>> > clang-tidy's
>> > predefined AST Matchers. The documentation for using clang-tidy
>> > (http://clang.llvm.org/extra/clang-tidy/) suggests that one should
>> > first
>> > try
>> > to use of predefined matchers listed in
>> > http://clang.llvm.org/docs/LibASTMatchersReference.html.
>> >
>> > But there is no matcher for C++11 [[attributes]]. There is matcher
>> > hasAttr,
>> > but it only works for predefined GCC __attribute__((s)).
>>
>> The hasAttr() matcher works for all attributes based on the Attr::Kind
>> enumeration. This will not distinguish between different spellings of
>> the same attribute, but that should (hopefully) be largely irrelevant.
>> So this matcher should do what you need already.
>
>
> Aaron, thanks for the reply. However it seams I phrased my question
> incorrectly. I would like to check the existence of my own unique
> attribute,
> say [[ab::cd::my_attribute]]. It is not in the list of any known
> attributes.
> hasAttr() appears to only detect the known attributes that are already
> listed in the long attribute enum. But will not see a new attribute.
>
> So my question is, in clang-tidy is it possible to inspect custom
> attributes, like [[ab::cd::my_attribute]] ?

If your custom attribute is implemented by adding the attribute to
Attr.td, then it should work fine (depending on your attribute
definition). The list of known attributes used by hasAttr() is
automatically generated from the attributes listed in Attr.td, and the
only attributes that don't get enumerated are ones which do not have
an AST node associated with them.

If your attribute is not added to Attr.td, then you are correct,
clang-tidy has no knowledge of it.

It might be useful to add a facility to Clang's AST to hold on to
unrecognized attributes (and to have an AST node type for that). Not every
application wants to recompile the guts of Clang just to handle users'
attributes, and might not be able to if it wants to handle attributes in
some generic way (so that the users aren't the people who are building the
tools).

I've had a long-term goal of adding pluggable attributes to Clang that
goes along these lines. As with many things though, it boils down to
an issue of lacking bandwidth. However, if someone with more bandwidth
would like to tackle this project, I'm happy to advise and review
work.

~Aaron

Thanks for a detailed. Response. I will try it out.

Regards,
&rzej;