Page MenuHomePhabricator

[analyzer] Port RetainSummaryManager to the new GenericCall interface, decouple ARCMT from the analyzer
ClosedPublic

Authored by george.karpenkov on Jan 23 2019, 4:39 PM.

Diff Detail

Repository
rC Clang

Event Timeline

NoQ accepted this revision.Jan 23 2019, 4:54 PM

*celebrates*

clang/lib/StaticAnalyzer/Checkers/RetainCountChecker/RetainCountChecker.cpp
337 ↗(On Diff #183208)

This line is unnecessary.

347–348 ↗(On Diff #183208)

This seems to benefit from some sort of CallEvent.getGenericCall() (?)

This revision is now accepted and ready to land.Jan 23 2019, 4:54 PM
This revision was automatically updated to reflect the committed changes.

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.

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

Should we remove this check that currently requires ENABLE_ARCMT => ENABLE_SA? http://llvm-cs.pcc.me.uk/tools/clang/CMakeLists.txt#441

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.

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?

@thakis Sorry I don't understand your point. At the end of the day, ProgramPoint and BodyFarm are only used by the static analyzer.

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.

Herald added a project: Restricted Project. · View Herald TranscriptFeb 8 2019, 6:36 AM