<div class="gmail_quote">On Tue Dec 16 2014 at 7:20:42 PM mobi phil <<a href="mailto:mobi@mobiphil.com">mobi@mobiphil.com</a>> 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> <br></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 class="gmail_quote"><div>So, why do you want to do that? What's your use case? :)</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>does your answer mean that it is impossible to tell clang to load the ast instead of re-parsing re-syntactic-analyzing the source?<br></div><div class="gmail_extra">Well, could throw back the ball and ask, why being able to save ast at all?<br></div></div></div></div></blockquote><div><br></div><div>Well, there are currently multiple use cases in clang: pch files (precompiled headers), pcm files (modules), and I think arcmigrate uses ASTUnit (but I don't know the details).</div><div> </div><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>I use at this moment clang infra mainly to understand clang itself. I gave the Sema.cpp as example as it is probably the hugest file (absolute size not counting included headers). Probably with headers included lot of compilation unit would be almost equally large. Anyway the point is that compilation takes lot of time. Trying to understand how much potential is in a workflow where one would generate only once the ast, and subsequent processes would reuse the AST as mentioned earlier (code generation, static analysis etc, refactoring experiments). Well, for applying different optmisation strategies, the LLVM intermediate could play similar role.</div></div></div></div></blockquote><div><br></div><div>The problem is that when you store the AST for a full TU, it's *huge* (all the transitive headers are in it) and I'm not sure why you would want to do that.</div><div>If you think tools are too slow, then our proposed solution for that is using C++ modules (which will also dump the AST, but in a much more nuanced and smart fashion).</div><div><br></div><div>That's why the use case matters; if you're interested in processing speed, the solution is modules (and the way it serializes the AST).</div><div>If your use case is something else, the answer might be something different :)<br><br></div><div> </div><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><br></div><div>As you can see, do not pretend to have a specific use case, but I also have the opinion that even simple features would never be asked explicitly as the threshold is a bit high, but these features would be probably used once present.</div><div><br></div><div><div class="gmail_extra">can you also eventually confirm that simple command line</div><div class="gmail_extra">clang Sema.ast<br></div><div class="gmail_extra">treats Sema.ast as pch and not as ast?<br></div></div><div><br></div><div><br></div><div>thanks and best regards</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>mobi phil</div></div></div></div></blockquote></div>