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 <[email protected]>wrote: > On Thu, Aug 30, 2012 at 3:02 PM, Ted Kremenek <[email protected]> wrote: > >> On Aug 30, 2012, at 2:50 PM, Ted Kremenek <[email protected]> wrote: >> >> On Aug 30, 2012, at 2:29 PM, Chandler Carruth <[email protected]> >> 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. =] > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
