<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 26, 2014 at 8:25 AM, 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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="">On Sun, May 25, 2014 at 5:53 PM, Allan Nielsen <span dir="ltr"><<a href="mailto:a@awn.dk" target="_blank">a@awn.dk</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">Hi,<br><br>I'm trying to write a program which uses libclang to refacture some code. To do<br>this I need to inspect the AST of the template arguments, but I can not figure<br>out how I can build a tree from the vistor callbacks.<br>


<br>Here is what my test source code looks like:<br><br>    1: template<typename ...T><br>    2: struct Foo {};<br>    3:<br>    4: static Foo<int, int, Foo<short, long>> foo;<br><br>When running the clang_visitChildren on this code I receive the following<br>


callbacks:<br><br>    (SYNTAX: <PARENT-CURSOR-HASH>/<CURSOR-HASH> <FILE>:<RANGE> <KIND> <DISPLAYNAME> <DISPLAYTYPE>)<br><br>    1/0 /tmp/test.cxx:1,1-2,14 31 Foo<T><br>    0/2 /tmp/test.cxx:1,10-23 27 T type-parameter-0-0<br>


    1/3 /tmp/test.cxx:4,1-43 9 foo Foo<int, int, Foo<short, long> ><br>    3/4 /tmp/test.cxx:4,8-11 45 Foo<br>    3/4 /tmp/test.cxx:4,22-25 45 Foo<br>    3/5 /tmp/test.cxx:4,40-43 103 Foo Foo<int, int, Foo<short, long> ><br>


<br>What confuses me is that all callbacks on line 4 has the same parent... So how<br>can I build a tree of the template arguments?<br><br>Should I be using the c++ API instead of the C-API for this?<br></div></blockquote>

<div><br></div></div><div>Front-loading by saying that I'm not an expert on the C-API:</div><div>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.</div>

<div>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).</div>

<div><br></div><div>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.</div>
</div></div></div></blockquote><div><br>Hi,<br><br>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...<br><br>Best regards<br>
Allan W. Nielsen<br><br></div></div></div></div>