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

[Manuel Klimek]

On Mon, Nov 18, 2013 at 5:47 PM, Jordan Rose <jordan_rose at apple.com> wrote:

>
> On Nov 18, 2013, at 0:17 , Manuel Klimek <klimek at google.com> wrote:
>
> 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
>
>
> It’s been a while since I’ve looked at the frontend-ish parts of the
> analyzer, but AFAICT it’s not actually using PPCallbacks in any way. I
> don’t think there’s any problem with jumping directly to the
> AnalysisConsumer.
>
> That said, if we ever want to add preprocessing-time checks, they wouldn’t
> be included in clang-tidy without a separate mechanism, but I think I’m
> okay with that. The current model is certainly intended to behave as an
> idempotent ASTConsumer.
>

Ah, cool - then I'll try that and see how it goes... Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131118/ab33c16b/attachment.html>