<div dir="ltr">I do believe the right way to do this sort of analysis is to shard per TU, output all the info you need in a format that fits your analysis, and then do the analysis on that data after sorting it into shards again.<div>Anything that tries to build up huge ASTs will not scale beyond small projects.</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 17, 2015 at 12:38 PM hao/NoQ <<a href="mailto:noqnoqneo@gmail.com">noqnoqneo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> dynamically merge in its corresponding AST (i.e. by loading a file from disk and using ASTMergeAction).<br>
<br>
A few problems with this approach include figuring out which<br>
translation unit needs to be picked up for merging (something you<br>
can't figure out from within a single clang compiler instance, without<br>
two-pass run through the build), incompleteness of the current<br>
implementation of the ASTImporter class (even though it has recently<br>
been significantly improved), and also there are numerous troubles<br>
with merging you may encounter, depending on the complexity of your<br>
project (eg., if the project is compiled for multiple architectures<br>
simultaneously, or has conflicting definitions in multiple translation<br>
units, etc.).<br>
<br>
Our team once had a look at this as well and made a simple<br>
proof-of-concept implementation, but it's not any close to<br>
release-able yet.<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" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>