To be correct, the code that I'm using for test, looks like this one:<br><br> std::set<int>::iterator it2 = s.begin();<br> find(it2,s.end(),i);<br><br><div class="gmail_quote">On 17 October 2012 19:00, Gábor Horváth <span dir="ltr"><<a href="mailto:xazax.hun@gmail.com" target="_blank">xazax.hun@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi!<br><br>I just tried out the new typedefType matcher. However there is one issue I encountered, maybe it is not intended to be used this way?<br>
<br>This matcher matches: callExpr(allOf(callee(functionDecl(hasName("std::find"))),<br>
hasArgument(0, hasType(type()))))<br><br>However this matcher do not match: callExpr(allOf(callee(functionDecl(hasName("std::find"))),<br> hasArgument(0, hasType(typedefType()))))<br>
<br>Do you have any idea what might be the problem? It compiles both ways.<br><br>Thanks,<br>Gábor<div class="HOEnZb"><div class="h5"><br><br><br><div class="gmail_quote">On 12 October 2012 11:59, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div class="gmail_extra"><div class="gmail_quote"><div>On Fri, Oct 12, 2012 at 10:48 AM, Gábor Horváth <span dir="ltr"><<a href="mailto:xazax.hun@gmail.com" target="_blank">xazax.hun@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
@Hal<br><br>I'm using the tooling library, which is primarily for stand-alone tools, however I think it is also possible to use the matchers in the frontend, however I don't know, if it is advised (maybe Daniel or Manuel can tell this). If it isn't advised, it will be better to use a recursive AST visitor for this reason. <br>
</blockquote><div><br></div></div><div>It's not yet adviced - we're working on that, but we want to have Doug & co. fully on board. One feature that's missing for that is being able to run matchers on arbitrary parts of the AST (not only the full AST).</div>
<div><div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
<br><div class="gmail_quote">On 11 October 2012 16:06, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
<br>
----- Original Message -----<br>
> From: "Gábor Horváth" <<a href="mailto:xazax.hun@gmail.com" target="_blank">xazax.hun@gmail.com</a>><br>
> To: "Manuel Klimek" <<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>><br>
> Cc: "Clang Developers" <<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a>><br>
> Sent: Thursday, October 11, 2012 7:39:50 AM<br>
> Subject: Re: [cfe-dev] Matching std::set::iterator<br>
><br>
><br>
> Yeah, I need this for a tool for my thesis (finding common stl<br>
> mistakes in code), but I can just use for example<br>
> "std::_Rb_tree_const_iterator", and mention in my thesis, the<br>
> current implementation only supports one certain STL implementation,<br>
> and will be improved in the future.<br>
><br>
> But when some experimental patches are available, I will be happy to<br>
> test them out.<br>
><br>
<br>
</div>[quasi-off-topic] I'm interested in how this turns out, not only because I think that STL warnings will be a great thing to have, but also because I'm interested in this optimization: I'd like to output TBAA metadata so that the backend understands that pointers into distinct std::vector objects (and maybe other containers?) don't alias. It seems that implementing this will require the same kind of technology as what you're doing.<br>
<br>
-Hal<br>
<div><div><br>
><br>
><br>
> On 11 October 2012 14:32, Manuel Klimek < <a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a> > wrote:<br>
><br>
><br>
><br>
> On Thu, Oct 11, 2012 at 1:28 PM, Gábor Horváth < <a href="mailto:xazax.hun@gmail.com" target="_blank">xazax.hun@gmail.com</a><br>
> > wrote:<br>
> > From my point of view, maybe something like matchesNameOrTypedef<br>
> > would be<br>
> > clean/easy. However I will be happy with any approach that provides<br>
> > an<br>
> > obvious interface. I think not being able to match typedefs is one<br>
> > of the<br>
> > biggest shortcomings of the matchers right now.<br>
><br>
> Can you work around that by specifying the names it has been<br>
> typedef'ed to for now?<br>
><br>
><br>
><br>
> ><br>
> ><br>
> > On 11 October 2012 14:14, Manuel Klimek < <a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a> ><br>
> > wrote:<br>
> >><br>
> >> On Thu, Oct 11, 2012 at 12:03 PM, Daniel Jasper <<br>
> >> <a href="mailto:djasper@google.com" target="_blank">djasper@google.com</a> ><br>
> >> wrote:<br>
> >>><br>
> >>> We should make that decisions together with the Type/TypeLoc<br>
> >>> matching.<br>
> >>> I think looking through typedefs needs to be done with matchers<br>
> >>> for<br>
> >>> types. matchesName()/hasName() on declarations should always look<br>
> >>> at<br>
> >>> the name of the type used for the declaration and not at an alias<br>
> >>> defined in a typedef.<br>
> >><br>
> >><br>
> >><br>
> >> I'm not sure I agree. It seems like the name property is really<br>
> >> one of the<br>
> >> decl or typedef, not one of the type.<br>
> >><br>
> >> I'm curious about other opinions, though...<br>
> >><br>
> >> Cheers,<br>
> >> /Manuel<br>
> >><br>
> >>><br>
> >>><br>
> >>> Cheers,<br>
> >>> Daniel<br>
> >>><br>
> >>> On Thu, Oct 11, 2012 at 11:47 AM, Manuel Klimek <<br>
> >>> <a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a> ><br>
> >>> wrote:<br>
> >>> > On Thu, Oct 11, 2012 at 11:05 AM, Gábor Horváth <<br>
> >>> > <a href="mailto:xazax.hun@gmail.com" target="_blank">xazax.hun@gmail.com</a> ><br>
> >>> > wrote:<br>
> >>> >> Hi!<br>
> >>> >><br>
> >>> >> It looks like<br>
> >>> >> ...hasType(namedDecl(matchesName("std::set.*iterator")))<br>
> >>> >> ...<br>
> >>> >> only tries to match ::std::_Rb_tree_const_iterator, but not<br>
> >>> >> std::set<foobar>::iterator, so I basicaly can't match<br>
> >>> >> typedefs. I<br>
> >>> >> think it<br>
> >>> >> is not possible to match on typedef-ed types right now.<br>
> >>> >><br>
> >>> >> There is one test case:<br>
> >>> >> EXPECT_TRUE(matches("typedef int X;", NamedX));<br>
> >>> >><br>
> >>> >> However it matches a typedef declaration. However if we wan't<br>
> >>> >> to match<br>
> >>> >> something like "X i;" later on, we can not do that, however it<br>
> >>> >> would<br>
> >>> >> be<br>
> >>> >> extremely useful.<br>
> >>> >><br>
> >>> >> Any comments on this?<br>
> >>> ><br>
> >>> > We need to write a matcher that supports this. We already have<br>
> >>> > some of<br>
> >>> > the supporting code for isDerivedFrom which looks through<br>
> >>> > typedefs.<br>
> >>> > We'll basically want to have a matcher matchesNameOrTypedef<br>
> >>> > (minus<br>
> >>> > finding a better name for the matcher ;) that does what you<br>
> >>> > want.<br>
> >>> ><br>
> >>> > Cheers,<br>
> >>> > /Manuel<br>
> >>> ><br>
> >>> >><br>
> >>> >> Thanks,<br>
> >>> >> Gábor<br>
> >>> >><br>
> >>> >><br>
> >>> >><br>
> >>> >> On 11 October 2012 09:39, Gábor Horváth < <a href="mailto:xazax.hun@gmail.com" target="_blank">xazax.hun@gmail.com</a><br>
> >>> >> > wrote:<br>
> >>> >>><br>
> >>> >>> Hi!<br>
> >>> >>><br>
> >>> >>> More details on matching template specializations. After<br>
> >>> >>> further<br>
> >>> >>> trials I<br>
> >>> >>> even tried this piece of code:<br>
> >>> >>><br>
> >>> >>><br>
> >>> >>> MatcherProxy StlCOAPPred::getMatcher()<br>
> >>> >>> {<br>
> >>> >>> TypeMatcher type = unless(anything());<br>
> >>> >>><br>
> >>> >>> for(const auto& e : gContainers)<br>
> >>> >>> type = anyOf(hasDeclaration(recordDecl(hasName(e))), type);<br>
> >>> >>><br>
> >>> >>> return id("id",<br>
> >>> >>> varDecl(allOf(hasType(<br>
> >>> >>><br>
> >>> >>> classTemplateSpecializationDecl(hasAnyTemplateArgument(<br>
> >>> >>><br>
> >>> >>><br>
> >>> >>> refersToType(hasDeclaration(hasDescendant(recordDecl(hasName("std::auto_ptr")))))))),<br>
> >>> >>> hasType(type))));<br>
> >>> >>> }<br>
> >>> >>><br>
> >>> >>> If I remove the hasDescendant, it works flawlessly for<br>
> >>> >>> example for<br>
> >>> >>> vector<auto_ptr<int>>, however it will not fork for<br>
> >>> >>> vector<vector<auto_ptr<int>>>. If I add that hasDescendant it<br>
> >>> >>> will<br>
> >>> >>> not match<br>
> >>> >>> anything. The same applies to the code I pasted in my mail<br>
> >>> >>> earlier.<br>
> >>> >>> If you<br>
> >>> >>> have any idea what could cause this issue, please tell me.<br>
> >>> >>><br>
> >>> >>> Thanks,<br>
> >>> >>> Gábor<br>
> >>> >>><br>
> >>> >>><br>
> >>> >>><br>
> >>> >>> On 10 October 2012 15:37, Gábor Horváth < <a href="mailto:xazax.hun@gmail.com" target="_blank">xazax.hun@gmail.com</a><br>
> >>> >>> > wrote:<br>
> >>> >>>><br>
> >>> >>>> For the second one, I altered my snippet:<br>
> >>> >>>><br>
> >>> >>>><br>
> >>> >>>> MatcherProxy StlCOAPPred::getMatcher()<br>
> >>> >>>> {<br>
> >>> >>>> TypeMatcher type = unless(anything());<br>
> >>> >>>><br>
> >>> >>>> for(const auto& e : gContainers)<br>
> >>> >>>> type = anyOf(hasDeclaration(recordDecl(hasName(e))), type);<br>
> >>> >>>><br>
> >>> >>>> return id("id",<br>
> >>> >>>> varDecl(allOf(hasType(recordDecl(hasDescendant(<br>
> >>> >>>><br>
> >>> >>>> classTemplateSpecializationDecl(hasAnyTemplateArgument(<br>
> >>> >>>><br>
> >>> >>>><br>
> >>> >>>> refersToType(hasDeclaration(recordDecl(hasName("std::auto_ptr"))))))))),<br>
> >>> >>>> hasType(type))));<br>
> >>> >>>> }<br>
> >>> >>>><br>
> >>> >>>><br>
> >>> >>>> But it does not seems to work. It do not give me any<br>
> >>> >>>> matches.<br>
> >>> >>>><br>
> >>> >>>> For the first one, I futher will investigate it later today,<br>
> >>> >>>> however<br>
> >>> >>>> my<br>
> >>> >>>> bet would be that, it tries to match<br>
> >>> >>>> "std::_Rb_tree_const_iterator".<br>
> >>> >>>><br>
> >>> >>>> Thanks,<br>
> >>> >>>> Gábor<br>
> >>> >>>><br>
> >>> >>>><br>
> >>> >>>> On 10 October 2012 13:55, Daniel Jasper < <a href="mailto:djasper@google.com" target="_blank">djasper@google.com</a><br>
> >>> >>>> > wrote:<br>
> >>> >>>>><br>
> >>> >>>>> +cfe-dev, please remember to include<br>
> >>> >>>>><br>
> >>> >>>>> I don't see anything generally wrong with your approach to<br>
> >>> >>>>> match<br>
> >>> >>>>> iterators. What I would do to debug this is locally editing<br>
> >>> >>>>> ASTMatchers.h to add a "llvm::outs() << FullName;" debug<br>
> >>> >>>>> output<br>
> >>> >>>>> into<br>
> >>> >>>>> the matchesName matcher. That way, you can see what it is<br>
> >>> >>>>> actually<br>
> >>> >>>>> trying to match.<br>
> >>> >>>>><br>
> >>> >>>>> The second question should work like:<br>
> >>> >>>>><br>
> >>> >>>>> varDecl(hasType(recordDecl(<br>
> >>> >>>>><br>
> >>> >>>>> hasDescendent(classTemplateSpecialization(hasAnyTemplateArgument(<br>
> >>> >>>>> refersToType(hasName("std::auto_ptr")))))))).bind("id")<br>
> >>> >>>>><br>
> >>> >>>>> This is just as a general idea, it might not yet be<br>
> >>> >>>>> correct.<br>
> >>> >>>>><br>
> >>> >>>>> Cheers,<br>
> >>> >>>>> Daniel<br>
> >>> >>>>><br>
> >>> >>>>> On Wed, Oct 10, 2012 at 1:23 PM, Gábor Horváth<br>
> >>> >>>>> < <a href="mailto:xazax.hun@gmail.com" target="_blank">xazax.hun@gmail.com</a> ><br>
> >>> >>>>> wrote:<br>
> >>> >>>>> > Hi!<br>
> >>> >>>>> ><br>
> >>> >>>>> > I want to create a matcher to match things like<br>
> >>> >>>>> > std::set<int>::iterator.<br>
> >>> >>>>> ><br>
> >>> >>>>> > I come up with this one: ...<br>
> >>> >>>>> > hasType(namedDecl(matchesName("std::set.*iterator"))) ...<br>
> >>> >>>>> > however it did not give me any match.<br>
> >>> >>>>> ><br>
> >>> >>>>> > Using the internal name of the iterator class like<br>
> >>> >>>>> > std::_Rb_tree_const_iterator would work, however that is<br>
> >>> >>>>> > implementation<br>
> >>> >>>>> > defined, so I do not want to rely on that one.<br>
> >>> >>>>> ><br>
> >>> >>>>> > Do you have any idea what am I doing wrong?<br>
> >>> >>>>> ><br>
> >>> >>>>> > My another question is, for example if I want to search<br>
> >>> >>>>> > for<br>
> >>> >>>>> > auto_ptr<br>
> >>> >>>>> > as<br>
> >>> >>>>> > template arguments in containers, I want to match<br>
> >>> >>>>> > vector<auto_ptr<int>> and<br>
> >>> >>>>> > also vector<vector<auto_ptr<int>>> ... etc.<br>
> >>> >>>>> ><br>
> >>> >>>>> > Is there any proper way to do it? My current solution:<br>
> >>> >>>>> ><br>
> >>> >>>>> > MatcherProxy StlCOAPPred::getMatcher()<br>
> >>> >>>>> > {<br>
> >>> >>>>> > TypeMatcher type = unless(anything());<br>
> >>> >>>>> ><br>
> >>> >>>>> > for(const auto& e : gContainers)<br>
> >>> >>>>> > type = anyOf(hasDeclaration(recordDecl(hasName(e))),<br>
> >>> >>>>> > type);<br>
> >>> >>>>> ><br>
> >>> >>>>> > auto templateSpecWithArgument = [](DeclarationMatcher<br>
> >>> >>>>> > decl) -><br>
> >>> >>>>> > DeclarationMatcher {<br>
> >>> >>>>> > return<br>
> >>> >>>>> ><br>
> >>> >>>>> ><br>
> >>> >>>>> > classTemplateSpecializationDecl(hasAnyTemplateArgument(refersToType(hasDeclaration(decl))));<br>
> >>> >>>>> > };<br>
> >>> >>>>> ><br>
> >>> >>>>> > // 1, 2, 3 times embedded<br>
> >>> >>>>> > DeclarationMatcher decl =<br>
> >>> >>>>> ><br>
> >>> >>>>> > anyOf(templateSpecWithArgument(recordDecl(hasName("std::auto_ptr"))),<br>
> >>> >>>>> ><br>
> >>> >>>>> ><br>
> >>> >>>>> ><br>
> >>> >>>>> > templateSpecWithArgument(templateSpecWithArgument(recordDecl(hasName("std::auto_ptr")))),<br>
> >>> >>>>> ><br>
> >>> >>>>> ><br>
> >>> >>>>> ><br>
> >>> >>>>> > templateSpecWithArgument(templateSpecWithArgument(templateSpecWithArgument(recordDecl(hasName("std::auto_ptr"))))));<br>
> >>> >>>>> ><br>
> >>> >>>>> ><br>
> >>> >>>>> > return<br>
> >>> >>>>> > id("id",varDecl(allOf(hasType(decl),hasType(type))));<br>
> >>> >>>>> > }<br>
> >>> >>>>> ><br>
> >>> >>>>> > I use templateSpecWithArgument, and nesting it. I could<br>
> >>> >>>>> > write a<br>
> >>> >>>>> > loop<br>
> >>> >>>>> > to do<br>
> >>> >>>>> > this nesting several times, however I think that could<br>
> >>> >>>>> > degrade<br>
> >>> >>>>> > the<br>
> >>> >>>>> > performance significantly (I did not measure yet).<br>
> >>> >>>>> ><br>
> >>> >>>>> > Thanks<br>
> >>> >>>>> > Gábor<br>
> >>> >>>><br>
> >>> >>>><br>
> >>> >>><br>
> >>> >><br>
> >>> >><br>
> >>> >> _______________________________________________<br>
> >>> >> cfe-dev mailing list<br>
> >>> >> <a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
> >>> >> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
> >>> >><br>
> >><br>
> >><br>
> ><br>
><br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
><br>
<br>
</div></div><span><font color="#888888">--<br>
Hal Finkel<br>
Postdoctoral Appointee<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</font></span></blockquote></div><br>
</div></div></blockquote></div></div></div><br></div>
</blockquote></div><br>
</div></div></blockquote></div><br>