clang-query: matchesName AST matcher insists on "::" prefix

[real-or-random]

Bugzilla Link	47879
Version	unspecified
OS	All
CC	@AaronBallman

Extended Description

$ echo "void foo(void) { }" > foo.c

$ clang-query foo.c -c 'match functionDecl(matchesName("^foo"))'
0 matches.

$ clang-query foo.c -c 'match functionDecl(matchesName("^::foo"))'

Match #​1:

/tmp/foo.c:1:1: note: "root" binds here
void foo(void) { }
^~~~~~~~~~~~~~~~~~
1 match.

This is clear from the code:

llvm-project/clang/include/clang/ASTMatchers/ASTMatchers.h

Line 2790 in 32d565b

std::string FullNameString = "::" + Node.getQualifiedNameAsString();

But it's at least unexpected, in particular for C code.

The matcher seems to be correctly used in a few places within the LLVM codebase. If this is the intended behavior, then the documentation is wrong.

[AaronBallman]

But it's at least unexpected, in particular for C code.

I agree that this is especially strange in C, where it's already hard enough to remember that '::Foo' is supported.

The matcher seems to be correctly used in a few places within the LLVM codebase. If this is the intended behavior, then the documentation is wrong.

This has been the behavior of the matcher since it was introduced 8 years ago: 1dad183#diff-fbafa44b28989eafe5795802cfefbad77b8cb6f6557a75ae2a8592afdb449147R794

I don't think this behavior was ever intended for C, but even for C++ it's a bit questionable given that "::foo" is a valid fully-qualified name that means "foo at the root namespace" (I would have expected the user would have to write "[A-Za-z0-9_]*::foo" in order to get the default behavior the matcher gives you). However, I'm not certain we want to invalidate 8 years' worth of user inertia behind the matcher and perhaps the most reasonable approach is to change the documentation to make these points more clear.

Manuel, what are your thoughts?