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

[Ted Kremenek]

On Aug 28, 2011, at 4:49 PM, Jordy Rose wrote:

> 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.)

Just to be clear, all I'm proposing is doing essentially what we do now, except pull it up one level so that the change applies to all checkers, and not just how we create ExprEngines.

> 
> My concern now is that storing the GC mode in the analysis context implies that it could change between code bodies.

By running the analysis twice, that's essentially what we are doing.

AnalysisContext implies just that: the "context" in which an analysis gets run.  No more and no less.  If GC is part of the context, that seems like a reasonable place to put it.

> Currently this isn't something we can cope with…

I'm not certain what that means.  Can you clarify?

> but worse, it means that checkers are created before they know what the GC mode is.

I don't anticipate that most checkers care, so I'm not certain if this is an issue.

> Unfortunately, checker registration functions only have access to a CheckerManager. CheckerManager does have a LangOptions reference, so maybe the GC flag should be there?

What problem are you trying to solve?  Checkers conditionally registering themselves depending on whether GC is enabled?  They can check the LangOptions reference for that.  If the GC or GC-hybrid mode is in LangOptions, it means GC-checking will happen.

> 
> (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.)

I'm not suggesting we change the LangOptions.  I'm suggesting that we run analyses with different AnalysisContexts.  We already do this, as right now each AnalysisContext encapsulates a separate function we want to analyze.  I'm suggesting we take that one step further, and have AnalysisContext also record the GC bit.

> 
> 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().

I'm thinking AnalysisContext::isGCEnabled().  I don't see this a property of CheckerManager at all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110829/7d24517b/attachment.html>