misleading mistake/type in ast matchers documentation

On the page,

http://clang.llvm.org/docs/LibASTMatchers.html

it is stated

“By default, matchers that accept multiple inner matchers use an implicit allOf(). This allows further narrowing down the match, for example to match all classes that are derived from “Bar”: recordDecl(hasName("Foo"), isDerivedFrom("Bar")).”

trying that with text based matchers, no result is returned. The correct would be

recordDecl(hasName("Foo"), isDerivedFrom(recordDecl(hasName("Bar")))

Or the text based matchers do not behave exactly as the equivalent C++ matchers?

do not care that much about this little mistake in the docu. (if it is a mistake). I care more to know if the string based matchers should behave exactly as the C++ matchers.

rgrds,
mobi phil

being mobile, but including technology
http://mobiphil.com

On the page,

http://clang.llvm.org/docs/LibASTMatchers.html

it is stated

“By default, matchers that accept multiple inner matchers use an implicit allOf(). This allows further narrowing down the match, for example to match all classes that are derived from “Bar”: recordDecl(hasName("Foo"), isDerivedFrom("Bar")).”

This works because isDerivedFrom has an overload that takes a StringRef.

trying that with text based matchers, no result is returned. The correct would be

recordDecl(hasName("Foo"), isDerivedFrom(recordDecl(hasName("Bar")))

Or the text based matchers do not behave exactly as the equivalent C++ matchers?

do not care that much about this little mistake in the docu. (if it is a mistake). I care more to know if the string based matchers should behave exactly as the C++ matchers.

I’m not sure that this is possible (cc’ed Sam); generally, the text based AST matchers will always be a simplified version, as they cannot rely on all the template magic going on.

On the page,

http://clang.llvm.org/docs/LibASTMatchers.html

it is stated

"By default, matchers that accept multiple inner matchers use an implicit
allOf()
<http://clang.llvm.org/docs/LibASTMatchersReference.html#allOf0Anchor>.
This allows further narrowing down the match, for example to match all
classes that are derived from “Bar”: recordDecl(hasName("Foo"),
isDerivedFrom("Bar"))."

This works because isDerivedFrom has an overload that takes a StringRef.

trying that with text based matchers, no result is returned. The correct
would be

recordDecl(hasName("Foo"), isDerivedFrom(recordDecl(hasName("Bar")))

Or the text based matchers do not behave exactly as the equivalent C++
matchers?

do not care that much about this little mistake in the docu. (if it is a
mistake). I care more to know if the string based matchers should behave
exactly as the C++ matchers.

I'm not sure that this is possible (cc'ed Sam); generally, the text based
AST matchers will always be a simplified version, as they cannot rely on
all the template magic going on.

This case is a simple function overloading, no templates involved. It is
supported in the dynamic matchers.
If isDerivedFrom() didn't accept a string it would give you an error
instead of "0 matches".
The problem here is that matchers created with the macros should not take
StringRef. This is causing a dangling pointer because the string passed to
the matcher constructor is destroyed before the matcher is executed.
Running under ASan shows the problem.

I'll send a fix for it.
Thanks for the report!

Hah, nice catch! Thanks for looking into it :slight_smile:

On the page,

http://clang.llvm.org/docs/LibASTMatchers.html

it is stated

"By default, matchers that accept multiple inner matchers use an
implicit allOf()
<http://clang.llvm.org/docs/LibASTMatchersReference.html#allOf0Anchor>.
This allows further narrowing down the match, for example to match all
classes that are derived from “Bar”: recordDecl(hasName("Foo"),
isDerivedFrom("Bar"))."

This works because isDerivedFrom has an overload that takes a StringRef.

trying that with text based matchers, no result is returned. The correct
would be

recordDecl(hasName("Foo"), isDerivedFrom(recordDecl(hasName("Bar")))

Or the text based matchers do not behave exactly as the equivalent C++
matchers?

do not care that much about this little mistake in the docu. (if it is a
mistake). I care more to know if the string based matchers should behave
exactly as the C++ matchers.

I'm not sure that this is possible (cc'ed Sam); generally, the text based
AST matchers will always be a simplified version, as they cannot rely on
all the template magic going on.

This case is a simple function overloading, no templates involved. It is
supported in the dynamic matchers.
If isDerivedFrom() didn't accept a string it would give you an error
instead of "0 matches".
The problem here is that matchers created with the macros should not take
StringRef. This is causing a dangling pointer because the string passed to
the matcher constructor is destroyed before the matcher is executed.
Running under ASan shows the problem.

I'll send a fix for it.
Thanks for the report!

Fixed at http://reviews.llvm.org/rL225180
_Sam

Thanks for the fix,

can confirm that now isDerivedFrom works with string parameter as well

sorry to insist, what about with renaming recordDecl to cxxRecordDecl, or
best to make recordDecl matching any RecordDecl (including C one's )

regards
mp