I think this would be more interesting with macros.
Eg triggering in code like this:

Is it a typo in the description when it says that when RemoveStar is on we will write 'auto*' instead if 'auto'?

Reformat code

So even if the above solution is working, we still need to call it that way (as a string):
clang-query> match castExpr(hasCastKind("CK_Dependent"))

Correct, that's expected behavior for clang-query (though I would love if someday we could expose actual enumerations somehow instead of string literals).

In D19871#419985, @aaron.ballman wrote:

In D19871#419954, @etienneb wrote:

In D19871#419947, @aaron.ballman wrote:

Is this required for some purpose?

It's used in clang-tidy checkers.

see http://reviews.llvm.org/D19841

It's good to have that context in a review for functionality that isn't part of the proposed patch. :-) Looking at the other patch, I would prefer to keep this matcher narrowed to just clang-tidy unless you can also solve how to expose it via the dynamic registry so that it can be used by tools like clang-query.

Thanks for doing this!

We can proceed with this change if you want, but it is not required anymore. I don't know whether we need the extra complexity of TemplateArgumentLess.

If this patch is not going to help with performance, I'm happy to abandon it.

Sent http://reviews.llvm.org/D19231 to fix the underlying bug in hasAncestor.
We can proceed with this change if you want, but it is not required anymore. I don't know whether we need the extra complexity of TemplateArgumentLess.

To be more specific, the problem comes from the use of hasAnscestor (done by isInTemplateInstantiation ) while there is a TemplateArgument in the bound nodes.
This tries to put the node into the cache.
To trigger this easily you only need to have a hit in the cache.
I think you can trigger it by adding a second line boost::lexical_cast<std::string>(42); in the string_as_T test. That second hit should get a cache hit and trigger the bug.

I think the bug is coming from memoizedMatchesAncestorOfRecursively.
memoizedMatchesRecursively has a special case at the top to skip the cache if the node is not sortable. The other function should do that too.
Although the check is stale also because it is only checking for memoizationData and not whether the node itself works for < and ==.

Those tests are testing the code completion you get in clang-query.
The type list must match what that matcher supports.

Change warning message.

Minor fixes

Minor fixes

In D18191#391168, @sdowney wrote:

At least in my codebase, skipping templates is too strong. I run across ones where the const& parameter is not one controlled by a template. It's often a size_t.

As Alex mentioned, we have a test like this.
It also adds a hardcoded list of user-defined types that are known to be better when passed by value (eg. StringRef)

This is already being done in http://reviews.llvm.org/D18582

In D18475#385789, @alexfh wrote:

Looks good to me. Adding Samuel, since he has done a lot of similar stuff by now and might have good ideas on improving this and making this more general.

Using new public hasAnyName API.

Minor fix

In D17811#380124, @jbcoe wrote:

Do you have commit access? I can apply this patch for you if not.

In D17986#379271, @baloghadamsoftware wrote:

I can rerun the script, however it seems it was not executed before the last commit on the master branch, thus if I rerun it then changes will appear in my diff which are not related to my work. What is the exect policy about running this scipt? Should it be rerun before the commit (then it was forgotten by the last committer) or it is executed only before releases?

Fixed on r263963.
Also added more tests to prevent such omissions in the future.

You are right. I'll send a fix for this and add those to the test.

Can you rerun the doc script (dump_ast_matchers.py)?

Please add a test for this.

Alex, this is what we discussed to make hasAnyName take a vector<StringRef> directly.

I will separate it, OK. In the Clang there is one use case that I fixed, although it did not break the tests. Neither of the other "has..." checkers (except the general ones) ignore implicit casts and parenthesized expressions so this one should not do it either because it makes checking implicit casts impossible.

The reason we haven't fixed hasAnyArgument is that it can potentially break its users.
I'd prefer if you separated the fix from the addition.
That way we can revert the fix if needed.

Minor fixes

In D17811#366482, @Eugene.Zelenko wrote:

Does it make D17772 obsolete?

I assume you checked that the new trait works on MSVC.
Aren't both the same type of expression SFINAE? Is somehow one supported but not the other?

Minor fix on comment