<div dir="ltr"><div>Unintentionally replied only to Sam, put back cfe-dev in CC.<br></div><div><br></div><div> </div><div>>> We should expose it, but with a different name. "Restrict" is still an implementation detail, imo.</div><div><br></div><div>for me the information is obviously more important. Indeed by outside world it should be sthg. like MatchFindReturnKind, but difficult to find a reasonable and short name.</div><div> </div><div>>>Any reason to not do this work directly on clang-query?</div><div>>>It would be awesome to have this support in an upstream tool.</div><div><br></div><div>this wants to be mainly an extension to "C" libclang or an independent library mainly to be used with scripting languages. The tool "cmatch" is just a prototype tool on top of the lib, but I started to use it to query ast-s, mainly clang and llvm codebase. Given long compilation times with C++ code (and obviously other reasons) IMHO  it is less time consuming to prototype refactoring tools etc. with scripting languages. The stuff in MatchFinder.cpp could be exposed to the C++ world as well, but lot of design decisions were taken having in mind the C and scripting lang world.<br></div><div><br></div><div>mobi phil</div><div><br></div><div class="gmail_extra">(bellow the last messages that did not reach the mailing list)<br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 7, 2015 at 7:04 PM, Samuel Benzaquen <span dir="ltr"><<a href="mailto:sbenza@google.com" target="_blank">sbenza@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Wed, Jan 7, 2015 at 12:30 PM, mobi phil <span dir="ltr"><<a href="mailto:mobi@mobiphil.com" target="_blank">mobi@mobiphil.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div><br></div></span><div>There is no getRestrictKind() because this is a new implementation detail and I've tried to keep it as such.</div><div>For example, recently I needed this information for an optimization and added DynTypedMatcher::canMatchNodesOfKind() instead of exposing RestrictKind directly.</div><div>If there is a good reason to make it part of the API, we can do that.</div><div>_Sam</div><div><br></div></div></div></div></blockquote><div><br></div></span><div>Sam, I perfectly agree with you, that too much to expose is not good. However this information is published in terms of documentation and not some internal hidden stuff. I need it for my tool, and I think other people could use it as it contains important information once the dynamic matcher is built. The use case for me is mainly shell based method chain completion based on the previously written match expression. I defined myself the method getRestrictedKind, and the tool works fine. (well for the moment -l parameter to list methods). </div></div></div></div></blockquote><div><br></div></span><div>We should expose it, but with a different name. "Restrict" is still an implementation detail, imo.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>git of the tool:<br><a href="https://github.com/mobiphil/cmatch" target="_blank">https://github.com/mobiphil/cmatch</a></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br><br></div><div>compiled with getRestrictedKind() defined I can use it as following. (return all methods that can be called on the resulting matched objects)<br> <br><div>-> src/cmatch  -l "varDecl()"</div><div>VarDecl:getCanonicalDecl</div><div>VarDecl:getMostRecentDecl</div><div>VarDecl:getDefinition</div><div>VarDecl:dumpColor</div><div>VarDecl:dump</div><div>VarDecl:getDeclKindName</div><div>VarDecl:getNameAsString</div><div>VarDecl:getUnderlyingDecl</div><div>VarDecl:getActingDefinition</div><div>VarDecl:getAnyInitializer</div><div>VarDecl:getDescribedVarTemplate</div><div>VarDecl:getInit</div><div>VarDecl:getInstantiatedFromStaticDataMember</div><div><br></div>This will be used for completion when writing method chain like<br><br>->src/cmatch -a SemaDecl.ast -m "methodDecl()" -r  getParent. < here completion is needed ><br></div><div><br></div></div></div></div></blockquote></span><div><br>Any reason to not do this work directly on clang-query?</div><div>It would be awesome to have this support in an upstream tool.</div><div><br></div><div>_Sam</div><div><br></div></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">rgrds,<br>mobi phil<br><br>being mobile, but including technology<br><a href="http://mobiphil.com">http://mobiphil.com</a></div>
</div></div>