rdar://19694750
Details
Diff Detail
Event Timeline
Can you elaborate a bit in what sense this decouples ARCMT from the analyzer? Can CLANG_ENABLE_STATIC_ANALYZER now be set independently of CLANG_ENABLE_ARCMT?
Also, isn't lib/Analysis a strange place for this? lib/Analysis is used by the compiler proper (CodeGen, Sema, …), while RetainSummaryManager is only used by tooling-like things (static analyzer, arcmigrate).
Can you elaborate a bit in what sense this decouples ARCMT from the analyzer?
ARCMT now does not need to link against the analyzer
Can CLANG_ENABLE_STATIC_ANALYZER now be set independently of CLANG_ENABLE_ARCMT?
Yes
Also, isn't lib/Analysis a strange place for this? lib/Analysis is used by the compiler proper (CodeGen, Sema, …), while RetainSummaryManager is only used by tooling-like things (static analyzer, arcmigrate).
Not only, it has utilities used by the static analyzer which are too generic to be in the static analyzer itself - ProgramPoint.cpp, BodyFarm.cpp, CocoaConventions.cpp to name a few.
Should we remove this check that currently requires ENABLE_ARCMT => ENABLE_SA? http://llvm-cs.pcc.me.uk/tools/clang/CMakeLists.txt#441
ProgramPoint.cpp and BodyFarm.cpp are used by StaticAnalyzer/Core, which the compiler itself uses for CFG-based warnings. Sema also uses CocoaConventions.
@thakis Sorry I don't understand your point. At the end of the day, ProgramPoint and BodyFarm are only used by the static analyzer.
If you disagree, what is your proposed directory structure? What would be the benefits?
Did you see the "Should we remove this check that currently requires ENABLE_ARCMT => ENABLE_SA? http://llvm-cs.pcc.me.uk/tools/clang/CMakeLists.txt#441" question?
They are used by StaticAnalyzer/Core, which clang does depend on.
If you disagree, what is your proposed directory structure? What would be the benefits?
I'd put this in a library that isn't linked into clang. The benefit is that it's easier to keep clang itself small(er) that way.
This line is unnecessary.