[cfe-dev] ast matchers, structDecl, unionDecl missing? recordDecl is only for CXXRecordDecl

[mobi phil]

Unintentionally replied only to Sam, put back cfe-dev in CC.


>> We should expose it, but with a different name. "Restrict" is still an
implementation detail, imo.

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.

>>Any reason to not do this work directly on clang-query?
>>It would be awesome to have this support in an upstream tool.

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.

mobi phil

(bellow the last messages that did not reach the mailing list)

On Wed, Jan 7, 2015 at 7:04 PM, Samuel Benzaquen <sbenza at google.com> wrote:

>
> On Wed, Jan 7, 2015 at 12:30 PM, mobi phil <mobi at mobiphil.com> wrote:
>
>>
>>> There is no getRestrictKind() because this is a new implementation
>>> detail and I've tried to keep it as such.
>>> For example, recently I needed this information for an optimization and
>>> added DynTypedMatcher::canMatchNodesOfKind() instead of exposing
>>> RestrictKind directly.
>>> If there is a good reason to make it part of the API, we can do that.
>>> _Sam
>>>
>>>
>> 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).
>>
>
> We should expose it, but with a different name. "Restrict" is still an
> implementation detail, imo.
>
>
>>
>> git of the tool:
>> https://github.com/mobiphil/cmatch
>>
>
>>
>> compiled with getRestrictedKind() defined I can use it as following.
>> (return all methods that can be called on the resulting matched objects)
>>
>> -> src/cmatch  -l "varDecl()"
>> VarDecl:getCanonicalDecl
>> VarDecl:getMostRecentDecl
>> VarDecl:getDefinition
>> VarDecl:dumpColor
>> VarDecl:dump
>> VarDecl:getDeclKindName
>> VarDecl:getNameAsString
>> VarDecl:getUnderlyingDecl
>> VarDecl:getActingDefinition
>> VarDecl:getAnyInitializer
>> VarDecl:getDescribedVarTemplate
>> VarDecl:getInit
>> VarDecl:getInstantiatedFromStaticDataMember
>>
>> This will be used for completion when writing method chain like
>>
>> ->src/cmatch -a SemaDecl.ast -m "methodDecl()" -r  getParent. < here
>> completion is needed >
>>
>>
> Any reason to not do this work directly on clang-query?
> It would be awesome to have this support in an upstream tool.
>
> _Sam
>
>


-- 
rgrds,
mobi phil

being mobile, but including technology
http://mobiphil.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150107/1e2a611f/attachment.html>