[cfe-commits] r162928 - in /cfe/trunk: include/clang/Frontend/AnalyzerOptions.h include/clang/Frontend/CompilerInvocation.h include/clang/StaticAnalyzer/AnalyzerOptions.h include/clang/StaticAnalyzer/Core/PathSensitive/AnalysisManager.h lib/Stati

[Chandler Carruth]

Turns out there is still a cycle.

lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp includes
include/clang/Rewrite/Rewriter.h

Several of the files in lib/Rewrite include include/clang/Frontend stuff,
so we have:

StaticAnalyzerFrontend -> Frontend -> StaticAnalyzerCore -> Rewrite ->
Frontend.

I see a lot of different ways to fix this, any preferences?



On Thu, Aug 30, 2012 at 3:20 PM, Chandler Carruth <chandlerc at google.com>wrote:

> On Thu, Aug 30, 2012 at 3:02 PM, Ted Kremenek <kremenek at apple.com> wrote:
>
>> On Aug 30, 2012, at 2:50 PM, Ted Kremenek <kremenek at apple.com> wrote:
>>
>> On Aug 30, 2012, at 2:29 PM, Chandler Carruth <chandlerc at google.com>
>> wrote:
>>
>> Yea, the only problem is that the SA/Frontend library depends heavily on
>> the Frontend library. We build all of the SA into a single library, but we
>> probably shouldn't. Because we do that, when we check the library-level
>> include layering, we find a cycle.
>>
>>
>> I'm not certain why the SA/Frontend library was created in the first
>> place.  Originally the Frontend library depended on the StaticAnalyzer, and
>> there was no cycle.  Conceptually SA/Frontend is more part of the Frontend
>> then the static analyzer, and that's how it was actually implemented at one
>> point.  At some point it seemed reasonable to move the static analyzer
>> specific parts of the Frontend into SA/Frontend out of the core Frontend
>> library.  This over-refactoring is what has led to this confusion.
>>
>>
>> Here is one question perhaps, which of the 3 SA sub-libraries should this
>> header belong to?
>>
>>
>> Probably StaticAnalyzerCore.
>>
>>
>> My unproductive vitriol aside, would it help for me to create a 4th
>> (leafy) library to include this leaf header?  It's not completely silly,
>> and would hopefully resolve this structuring issue.
>>
>
> Nope, I'm quite happy putting this in the core sublibrary. =]
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120831/4e67e5f3/attachment.html>