[cfe-dev] Proposed: change tracking for RegionStore

[Jordy Rose]

On Mon, 9 Aug 2010 21:00:03 -0700, Ted Kremenek <kremenek at apple.com>
wrote:
> On Aug 9, 2010, at 3:50 PM, Jordy Rose wrote:
> 
>> Right. I was uneasy about this, but I think it actually ought to stay.
>> Why? Any region invalidation should be picked up by the checkers
>> eventually, or we have a correctness problem. (It's /because/
>> invalidating
>> a set of regions might touch other regions that this is necessary --
even
>> an internal use has no guarantee of a controlled invalidation.)
>> 
>> If you think it's necessary, I'll change it, but I think it may
actually
>> be needed now.<CStringChecker.cpp>
> 
> With the reference, it just seems like we must pay the cost of this
every
> time we use InvalidateRegions.  If there are no checkers that consume
this
> information, we always pay the cost.  That's the reason why
> InvalidatedSymbols is a pointer.

Makes sense. Here's a version using a pointer and a check beforehand to
see if any regions are interested. The whole WantsRegionChangeUpdate
structure seems awkward to me, though. It's not being called for bindLoc()
and bindDefault() because it doesn't have any benefit there, and checkers
that return false from WantsRegionChangeUpdate can still be called for
ProcessRegionChanges if some other checker wants an update. Which,
unfortunately, means we can't promise checkers that ProcessRegionChanges
won't be called even if they don't want the update.

I suppose we could make a list of checkers that were interested and use
/that/ later on. If we did that, though, we'd have the odd case of
ProcessRegionChanges taking an array of checkers as an argument. We could
move the whole invalidation logic from GRStateManager into GRSubEngine, but
most of it really isn't engine or checker logic -- it's just
store-and-state code like all the others.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ProcessRegionChanges.2.patch
Type: text/x-diff
Size: 18830 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100811/4b1ca974/attachment.patch>