Moving AnalysisConsumer.h/cpp out of tools/clang-cc

I've just finished some work with the command-line options for
AnalysisConsumer, so that it's a possibility to move the header into
include/clang/ and the corresponding .cpp file into lib/. Is there
anything else I should change before moving it? Also, I'm not sure
where to move it; would include/clang/Frontend or
include/clang/Analysis be more appropriate? (I'm thinking Frontend is
more appropriate, but I'm not sure.)

-Eli

I think it is fine to move it to lib/Frontend.

To be honest, I'm not 100% certain what removing the command line options logic from AnalysisConsumer.cpp buys us, although I do understand the motivation of having clang-cc.cpp responsible for the command line options and libFrontend responsible for the logic. Still, this separation makes it more cumbersome to add new analysis-specific command-line options.

Originally all of the analysis-specific options were in clang-cc.cpp (then clang.cpp), with the necessary flags passed as function arguments to CreateAnalysisConsumer. While this created a "clean" separation of concerns from the options-processing point of view, it meant that every time a new option was added 2-3 files had to get modified. This kind of sucked, which is why I got lazy and stopped doing it, but I admit I wasn't doing things as intelligently as I could.

Anyway, I still think moving AnalysisConsumer.cpp to libFrontend is the right thing to do.

Thanks for tackling this Eli.

Ted

I've just finished some work with the command-line options for
AnalysisConsumer, so that it's a possibility to move the header into
include/clang/ and the corresponding .cpp file into lib/. Is there
anything else I should change before moving it? Also, I'm not sure
where to move it; would include/clang/Frontend or
include/clang/Analysis be more appropriate? (I'm thinking Frontend is
more appropriate, but I'm not sure.)

-Eli

I think it is fine to move it to lib/Frontend.

Hi Eli,

To follow up, I think lib/Frontend is a better choice because lib/Analysis should not be aware of PlistDiagnosticClient or HTMLDiagnosticClient. For me it is desirable to leave lib/Analysis being "core analysis" logic and keep the rendering of diagnostics and driver logic completely separate. Parts of AnalysisConsumer.cpp may migrate to lib/Analysis over time, but that is something that doesn't need to be tackled now.

To be honest, I'm not 100% certain what removing the command line options logic from AnalysisConsumer.cpp buys us, although I do understand the motivation of having clang-cc.cpp responsible for the command line options and libFrontend responsible for the logic. Still, this separation makes it more cumbersome to add new analysis-specific command-line options.

Originally all of the analysis-specific options were in clang-cc.cpp (then clang.cpp), with the necessary flags passed as function arguments to CreateAnalysisConsumer. While this created a "clean" separation of concerns from the options-processing point of view, it meant that every time a new option was added 2-3 files had to get modified. This kind of sucked, which is why I got lazy and stopped doing it, but I admit I wasn't doing things as intelligently as I could.

I'm going to backpedal a bit on this one. For me it would be nice that adding an analysis option took just one line of code, which is why I started putting command line option definitions in AnalysisConsumer.cpp. I realize, however, that this can be accomplished in different ways while still satisfying our layering goals.

Thanks again Eli for tackling this!