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

Sean Silva silvas at purdue.edu
Sun Nov 17 02:48:05 PST 2013


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.

-- 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/20131117/342fc7d5/attachment.html>


More information about the cfe-dev mailing list