r178518 - [analyzer] Teach invalidateRegions that regions within LazyCompoundVal need to be invalidated

[Jordan Rose]

On Apr 3, 2013, at 9:00 , Anna Zaks <ganna at apple.com> wrote:

> 
> On Apr 2, 2013, at 8:46 PM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
>> 
>> On Apr 2, 2013, at 19:48 , Anna Zaks <ganna at apple.com> wrote:
>> 
>>> 
>>> On Apr 2, 2013, at 6:42 PM, Jordan Rose <jordan_rose at apple.com> wrote:
>>> 
>>>> 
>>>> On Apr 2, 2013, at 10:11 , Anna Zaks <ganna at apple.com> wrote:
>>>> 
>>>>> 
>>>>> On Apr 1, 2013, at 6:44 PM, Jordan Rose <jordan_rose at apple.com> wrote:
>>>>> 
>>>>>> Top-level regions" doesn't have any actual meaning—it's only used for RetainCountChecker, and when I invented it for that it meant "arguments, plus the receiver I guess". But I see your point that that "plus the receiver" is more work than callers should have to do. Thanks for the explanation of the thought process.
>>>> 
>>>> 
>>>> (Maybe I'd be happier if the top-level and non-top-level sets were tied together in a struct, but that can wait until we support non-top-level const regions.)
>>>> 
>>> 
>>> Yes, wrapping these in a struct would be better. However, RetainCountChecker aside, there is only notifyCheckersOfPointerEscape that consumes the extra region (and it does need to know the difference between top-level and not).
>> 
>> Well, in theory...in practice, no one's taking advantage of it!
>> 
> I see. 
> 
> So ideally, we would replace the code in RetainCountChecker to use escape callback (assuming it can deal with regions escaping into structs). Than, we would write custom code there to differentiate between arguments + self, and not. Finally, we would remove the top level from everywhere else. Correct?

Right, that seems reasonable. It's not urgent, but it does make the API a little simpler by reducing the number of things we pass around. OTOH, it's possible someone else will need this functionality in the future, in which case we'd have to put it right back.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130403/081e3eb2/attachment.html>