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

[Ted Kremenek]

On Aug 29, 2011, at 11:49 PM, Jordy Rose wrote:

> Ah. I was thinking something like this:
> 
> 1. GC Disabled
> a) create CheckerManager and register checkers
> b) run non-path-sensitive analyses
> c) run path-sensitive analyses
> 2. GC Enabled
> a) create CheckerManager and register checkers
> b) run non-path-sensitive analyses
> c) run path-sensitive analyses
> 

Let's call this plan A.

> It sounds like you're thinking:
> 
> 1. Create CheckerManager and register checkers
> 2. Mgr->setGCEnabled(true)
> a) run non-path-sensitive analyses
> b) run path-sensitive analyses
> 3. GC Enabled
> a) run non-path-sensitive analyses
> b) run path-sensitive analyses

Let's call this plan B.

> 
> ...and then checkers check if GC is enabled every time it's interesting, instead of once at registration time.

That's clearer.  I think your plan sounds cleaner (plan A).  Couple concerns:

(1) I still want checkers to be written so that if they want GC-specific logic, they don't need to be written as a separate checker.  For the Retain/Release checker, we can still keep conditional behavior just by passing the "GC enabled" flag to the checker at construction time.

(2) While I'm fine with checkers being run multiple times, we're still going to want to merge duplicate diagnostics.

For (2), I'm thinking we need a step 0.  e.g.:

0. Create a single PathDiagnosticClient that batches all results and uniques them.  Use this PathDiagnosticClient for everything.  We can put this logic into the PathDiagnosticClient base class.
1. GC Disabled
a) create CheckerManager and register checkers
b) run non-path-sensitive analyses
c) run path-sensitive analyses
2. GC Enabled
a) create CheckerManager and register checkers
b) run non-path-sensitive analyses
c) run path-sensitive analyses

Currently BugReporter does some uniquing of reports, and that's fine to keep (it serves a different purpose), but I think we'll want an easy way to unique all the diagnostics from all checkers.  That also can be used as a mechanism to solve the problem of printing all diagnostics in SourceLocation order to the terminal.

Of course, we can add step 0 later, but we need to account for it in the design.

What do you think?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110830/3fb60bbc/attachment.html>