[cfe-dev] Making FrontendActions composable (or not)

[Manuel Klimek]

On Sun, Nov 17, 2013 at 11:48 AM, Sean Silva <silvas at purdue.edu> wrote:

> 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.
>

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.

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...

Cheers,
/Manuel


>
> -- Sean Silva
>
>
> On Fri, Nov 15, 2013 at 10:48 AM, Manuel Klimek <klimek at google.com> wrote:
>
>> Heya,
>>
>> 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.
>>
>> I see multiple ways to solve this problem, but don't really know what the
>> best way to go forward is:
>> 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
>> 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
>>
>> Thoughts?
>> /Manuel
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131118/d5074577/attachment.html>