ignoring*() and hasParent() matchers

Hello all,

When using has*() it is sometimes desirable to use ignoringParenCasts(), for example (from the docs):

varDecl(hasInitializer(ignoringParenCasts(integerLiteral())))

Is there any way to get the same effect when hasParent(), e.g.:

integerLiteral(hasParent(ignoringParenCasts(varDecl())))

Obviously this does not work, but what is the best way to achieve a similar effect?

cheers,

Mike

I ended up writing my matcher like this:

integerLiteral(
expr().bind("literal"),`` //inline bind call using a redundant node matcher
hasAncestor( //climb up the AST to the nearest varDecl`` ancestor
varDecl(hasInitializer(ignoringParenCasts(equalsBoundNode("literal")))) //check that this varDecl satisfies the original condition
)
)

Any feedback is appreciated, as I am completely new to LibTooling…

P.S.: The actual matcher I am working on is far more complicated. Inverting it (i.e. using my very first example) would result in much more difficult problems. Although this seems like a roundabout hack, it might be effective when nested inside matchers that have already been tested

Thanks,

Mike

That’s what I’d do, too.

Thanks for the confirmation. I have learned a lot from your great talks/presentations :slight_smile:

Thanks,

Mike

Thanks! You can pay that back by giving a talk about clang tooling from a user’s point of view at some point, as you seem to have mastered the subject :slight_smile:

I have also been through the learning experience of mastering AST matchers.
I just need to find a venue to give a long enough talk at now! I aim to
write some blog posts too, and might be in touch to get some review.

Thanks,

Stephen.

Thanks! You can pay that back by giving a talk about clang tooling from a
user’s point of view at some point, as you seem to have mastered the
subject :slight_smile:

I have also been through the learning experience of mastering AST matchers.
I just need to find a venue to give a long enough talk at now! I aim to
write some blog posts too, and might be in touch to get some review.

Awesome!

I am certainly planning to invest some time writing blog posts/scripts to make clang-tidy checks easier to use. Giving a talk seems a bit impossible in the near future, as there isn’t much interest in clang in my local community (hope that this changes).

Also, I have written some scripts (that are meant to be used in continuous integration) to get clang-tidy/clang-format output as comments in popular web-based git repo managers (e.g. github, gitlab, bitbucket, …). This can help enforce some coding conventions when reviewing code changes. Here is a screenshot on gitlab (I’ll be deploying this into production soon):

Sorry for the long email, Just wanted to share my enthusiasm :smiley:

Thanks again,
Mike

This would be an awesome topic for a talk or tutorial at one of the semi-annual LLVM Developer Meetings. Just saying.

–paulr