[cfe-dev] misleading mistake/type in ast matchers documentation

Manuel Klimek klimek at google.com
Sun Jan 4 07:35:29 PST 2015


On Sun Jan 04 2015 at 4:22:08 PM Samuel Benzaquen <sbenza at google.com> wrote:

> On Sat, Jan 3, 2015 at 10:19 AM, Manuel Klimek <klimek at google.com> wrote:
>
>>
>>
>> On Thu Dec 25 2014 at 8:50:46 PM mobi phil <mobi at mobiphil.com> wrote:
>>
>>> 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.
>

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


> Thanks for the report!
>
>
>>
>>
>>>
>>> rgrds,
>>> mobi phil
>>>
>>> being mobile, but including technology
>>> http://mobiphil.com
>>>  _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150104/21a2ec25/attachment.html>


More information about the cfe-dev mailing list