<div dir="ltr"><div><div>Hi Jordan,<br><br></div>I have some questions. First of all I do not really know yet if it would be better to create a new compiler instance to parse the model files or reuse the existing compiler instance.<br>
<br></div>In either case the current FrontendAction logic does not fit in the scenario. I could create a new class that is derived  from FrontendAction that uses an existing ASTContext to parse a file, however the BeginSourceFile, Execute, and EndSourceFile methods are not virtual (and they contain logic that prevents using FrontendAction as a base class for this task). I think they might not be virtual on purpuse. Do you think that it would be ok to change those methods to be virtual?<br>
<br>Thanks,<br>Gábor<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 22 May 2014 05:50, Jordan Rose <span dir="ltr"><<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Ah, okay...I thought this was for arbitrary other files in the project. Doing this for synthesized bodies seems much more plausible!</div>
<span class="HOEnZb"><font color="#888888"><div><br></div><div>Jordan</div></font></span><div><div class="h5"><div><br></div><br><div><div>On May 21, 2014, at 20:46 , Ted Kremenek <<a href="mailto:kremenek@apple.com" target="_blank">kremenek@apple.com</a>> wrote:</div>
<br><blockquote type="cite"><div style="word-wrap:break-word">Hi Jordan,<div><br></div><div>The goal here is to use source code to replace the synthesis of body summaries provided by BodyFarm rather than the ASTs being hand-crafted by BodyFarm.  BodyFarm obviously depends on the types being available for parameters and such, and I think the same requirements could be here as well.  Thus the idea is to lazily create ASTs from source when we ask BodyFarm to synthesize the body of a function, and utilize all the existing declared types, language options, etc., from the current ASTContext.  If some if the dependencies cannot be resolved, a reasonable solution would be to fall back and fail to synthesize a body.</div>
<div><br></div><div>Ted</div><div><br><div><blockquote type="cite"><div>On May 21, 2014, at 8:16 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>> wrote:</div><br><div>
<div style="word-wrap:break-word"><div>Hi, Gábor. If you look far back in the SVN history you can see sketches of where we tried this, with an unimplemented concept of "marshalling" used to get data from one ASTContext to another. As I remember, it didn't go very far because it turns it out it's very difficult to actually match up types and decls from different translation units.</div>
<div><br></div><div>Trying to <i>parse</i> new code could have better luck, though you'd probably have to change the way things are currently set up to not count the main source file as ended. You could still run into trouble if there are, say, static functions with the same name in the other TU, though.</div>
<div><br></div><div>I'm not sure what you mean by "some type information may not be available in those external source files". You can't actually parse C code fully without type information, because certain constructs are ambiguous otherwise.</div>
<div><br></div><div>The approach we've considered before is to come up with some AST-agnostic "summary" of a function, like "the first parameter is never modified even though it's passed as non-const, and the second parameter is always the return value". A more advanced form of this would allow checkers to store information this way as well. Then this summary information could be "applied" at a call site (using the declaration in the primary TU), without having to worry about making the ASTs match up. This summary information could also be persisted, meaning that when you reanalyze the same project you wouldn't have to generate the summaries all over again.</div>
<div><br></div><div>Of course, you don't have to do things this way. I'm just concerned that C is very much structured around the notion of translation units, and that it will be very difficult to handle code outside of that context.</div>
<div><br></div><div>If you have any specific questions, I'll try to answer them fairly promptly. Anna should be coming back soon, too.</div><div>Jordan</div><div><br></div><br><div><div>On May 19, 2014, at 11:37 , Gábor Horváth <<a href="mailto:xazax.hun@gmail.com" target="_blank">xazax.hun@gmail.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr"><div><div><div><div><div>Hi!<br><br></div>I am working on a Google Summer of Code project to improve the Clang Static Analyzer. In that project it would be essential to parse external source files and inject AST into the translation unit that is being compiled. The external files would contain definitons that are being looked up. The goal would be to avoid runtime cost if no lookup is required. So basicly I want to add new code lazily to an existing AST after parsing is done by injecting new source code. <br>

<br></div>Moreover some type information may not be available in those external source files, so type information in the translation unit that is being analyzed should be utilized.<br><br></div>What do you think, what would be the most efficient and elegant way to approach this problem? <br>

<br></div>Thanks in advance,<br></div>Gábor<br></div>
_______________________________________________<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" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div>_______________________________________________<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" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></blockquote></div><br></div></div></blockquote></div><br></div></div></div></blockquote></div><br></div>