[cfe-dev] Using libclang to inspect the AST of template arguments

[Allan Nielsen]

On Mon, May 26, 2014 at 8:25 AM, Manuel Klimek <klimek at google.com> wrote:

> On Sun, May 25, 2014 at 5:53 PM, Allan Nielsen <a at awn.dk> wrote:
>
>> Hi,
>>
>> I'm trying to write a program which uses libclang to refacture some code.
>> To do
>> this I need to inspect the AST of the template arguments, but I can not
>> figure
>> out how I can build a tree from the vistor callbacks.
>>
>> Here is what my test source code looks like:
>>
>>     1: template<typename ...T>
>>     2: struct Foo {};
>>     3:
>>     4: static Foo<int, int, Foo<short, long>> foo;
>>
>> When running the clang_visitChildren on this code I receive the following
>> callbacks:
>>
>>     (SYNTAX: <PARENT-CURSOR-HASH>/<CURSOR-HASH> <FILE>:<RANGE> <KIND>
>> <DISPLAYNAME> <DISPLAYTYPE>)
>>
>>     1/0 /tmp/test.cxx:1,1-2,14 31 Foo<T>
>>     0/2 /tmp/test.cxx:1,10-23 27 T type-parameter-0-0
>>     1/3 /tmp/test.cxx:4,1-43 9 foo Foo<int, int, Foo<short, long> >
>>     3/4 /tmp/test.cxx:4,8-11 45 Foo
>>     3/4 /tmp/test.cxx:4,22-25 45 Foo
>>     3/5 /tmp/test.cxx:4,40-43 103 Foo Foo<int, int, Foo<short, long> >
>>
>> What confuses me is that all callbacks on line 4 has the same parent...
>> So how
>> can I build a tree of the template arguments?
>>
>> Should I be using the c++ API instead of the C-API for this?
>>
>
> Front-loading by saying that I'm not an expert on the C-API:
> 1. You want to use the C-API if you need a library that is stable, and
> provides for backwards compatibility going forward. That is, if you want to
> write this tool once, and than use it for years without ever having to
> touch it, the C API is your only hope.
> 2. As you discovered, the C API makes some power uses harder; I don't know
> whether what you want to do is possible with the C API, but I'd say that
> it's quite a bit easier with the C++ API; that said, if you use the C++
> API, you'll have to recompile your tool when you want to use a newer clang,
> and there are sometimes breaking interface changes, for which you'll have
> to adapt your code (that said, those interface changes are not a big issue
> - we have many tools against the C++ API we maintain, and have not found
> that to be an issue - the "being willing to recompile" is the much larger
> barrier-to-entry, I think).
>
> So, I'd cautiously advice you to use the C++ API if you're coding in C++
> anyway, and you don't want to ship a tool that can auto-link against
> different versions of clang to customers.
>

Hi,

Thanks for the advice, I will look into using the C++-API instead. The only
reason why I have chosen the C-API was that it seem easier to get started
with...

Best regards
Allan W. Nielsen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140526/afa24ac2/attachment.html>