[cfe-dev] CFRefCount Problem #4: Hybrid GC

[Jordy Rose]

Okay. Your reasoning makes sense, and you've got a stronger sense of how the analyzer pieces fit together. TBH if output order isn't a factor, then #3 (two passes over the entire translation unit) requires the least from the actual checking. It's a fully top-down solution, rather than a bottom-up solution. (What we have now is somewhere in the middle.)

My concern now is that storing the GC mode in the analysis context implies that it could change between code bodies. Currently this isn't something we can cope with...but worse, it means that checkers are created before they know what the GC mode is. Unfortunately, checker registration functions only have access to a CheckerManager. CheckerManager does have a LangOptions reference, so maybe the GC flag should be there?

(Currently there are a lot of checkers that fail if the /AST context/ changes between code bodies...mostly those that still cache IdentifierInfos. This isn't correct behavior, but it's roughly equivalent to the case here, which is essentially changing LangOptions between code bodies.)

For checkers that might want to make incidental checks, rather than change their whole behavior, we could put a shortcut method in CheckerContext that just expands to getAnalysisManager().getCheckerManager()->isGCEnabled().

Jordy


On Aug 28, 2011, at 16:04, Ted Kremenek wrote:
[snip]

> My suggestion is we run the analyses twice in AnalysisConsumer, having the resulting AnalysisContext's indicate the memory model.  Then ExprEngine is not in the business completely of even reasoning about the memory model.
> 
> The result is something that is trivially simple.
> 
> The downside?  Yes, all analyses (including path-insensitve ones) get run twice.  I'm not concerned about this for two reasons:
> 
> 1) Dual GC mode is an exception, and not the norm.  It's not worth optimizing for.
> 
> 2) Keeps things simple.  Everywhere we introduce unnecessarily inherently complexity into the analyzer I think we really lose in the long run.
> 
> I also think the "running things twice" can be potentially mitigated by other means, say using multiple cores for analyzing a translation unit.