On Aug 16, 2013, at 2:09 PM, Benjamin Kramer <[email protected]> wrote:
> So far ARCMigrate was not allowed to use the static analyzer. Should this
> policy be changed (with the implication of linking the static analyzer into
> libclang) or should ObjCRetainCount move to another place (lib/Analysis?)
> where it can be used from multiple components?
Reasonable points.
Stepping back, I believe that this code probably belongs where it is. The
split between libAnalysis and libStaticAnalyzer is fairly loose, but roughly
libAnalysis is the analysis stuff that can be used by the core compiler. I
don’t see a reason to prohibit other tools, such as any migrator or refactoring
tool, from using pieces of the static analyzer.
The static analyzer is a library, just like the rest of Clang. Static analysis
and refactoring are very related technologies and I see that synergy increasing
in the future; there’s no reason to not be able to employ those analyses within
the migrator, and we shouldn’t need to rip apart the static analyzer for this
purpose. If this logic was being used by the core compiler that would be a
different story (which is why libAnalysis was separated from libStaticAnalyzer
in the first place), but it isn’t.
As for libStaticAnalyzer being linked into libclang, if libclang needs to get a
bit bigger to support more functionality, then we should not be scared about
it. The linker should also be able to strip out what isn’t used.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
