<div dir="ltr">On Mon, Nov 18, 2013 at 9:47 AM, Sean Silva <span dir="ltr"><<a href="mailto:silvas@purdue.edu" target="_blank">silvas@purdue.edu</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="im">On Mon, Nov 18, 2013 at 3:17 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>On Sun, Nov 17, 2013 at 11:48 AM, Sean Silva <span dir="ltr"><<a href="mailto:silvas@purdue.edu" target="_blank">silvas@purdue.edu</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>It seems weird to be using FrontendAction for clang-tidy (and the analyzer too). clang-tidy isn't a compiler frontend (I mean look at the methods: hasCodeCompletionSupport? getCurrentFileKind? shouldEraseOutputFiles?). AFAICT All you are really need is a vector of PPCallbacks, and a vector of what is effectively std::function<TidyResult(ASTContext &)>. It seems like there should be at most a single FrontendAction which just sets things up so that it can forward everything down into those vectors.</div>
</div></blockquote><div><br></div></div><div>That is basically what I proposed as "b". The problem with that is that this is not how the static analyzer is currently factored - if I want to pull it apart into a PPCallbacks and an ASTConsumer, I have to duplicate significant amounts of code. Thus, if we want to go that way, the next step is to make the static analyzer more modular: basically pull out a class that can give you both the PPCallbacks and the ASTConsumer. But on the other hand, such a class already exists - it is the static analyzer's FrontendAction; it is exactly what we want, namely a "factory" class (well, in the broader sense) of a PPCallbacks and ASTConsumer instance, which happens to also be able to put the compiler into the state it needs it in.</div>
</div></div></div></blockquote><div><br></div></div><div>I'm not sure I understand what you mean by "put the compiler into the state it needs it in". That seems like it completely violates the encapsulation (I'm imagining something like it twiddling LangOptions; that would wreak havoc on everything else...).</div>
</div></div></div></blockquote><div><br></div><div>Sorry, I worded that incorrectly - it pulls various parts of configuration information out of the compiler.</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"><span class="HOEnZb"><font color="#888888">
<div><br></div><div>-- Sean Silva</div></font></span><div class="im"><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>Perhaps when you argue on the interface level, you mean "there should really be something in between a FrontendAction and an ASTConsumer or PPCallbacks interface", and perhaps you're right, but that sounds like a much bigger change...</div>
<div><br></div><div>Cheers,</div><div>/Manuel</div><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><br></div><div>-- Sean Silva</div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Fri, Nov 15, 2013 at 10:48 AM, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Heya,<div><br></div><div>while trying to integrate the static analyzer with clang-tidy I ran into the problem of combining the static analyzer's FrontendAction with clang-tidy's. As most of FrontendAction's methods are protected it is not straight forward to write a combiner/forwarder.</div>
<div><br></div><div>I see multiple ways to solve this problem, but don't really know what the best way to go forward is:</div><div>a) create a CombinedFrontendAction (either by befriending FrontendAction, or lowering its access boundaries); I assume that the protectedness in FrontendAction exists for a reason, so there might be downsides to this I'm not aware of</div>
<div>b) modularize the Analyzer enough to be able to run it as a PPCallback / ASTConsumer which is registered by a one-off FrontendAction; the problem with this approach is that when we want to build higher-level tools, we always need to keep that split</div>
<div><br></div><div>Thoughts?</div><span><font color="#888888"><div>/Manuel</div></font></span></div>
<br></div></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>
<br></blockquote></div><br></div>
</blockquote></div></div><br></div></div>
</blockquote></div></div><br></div></div>
</blockquote></div><br></div></div>