[cfe-commits] r161357 - in /cfe/trunk: include/clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h lib/StaticAnalyzer/Checkers/CMakeLists.txt lib/StaticAnalyzer/Checkers/Checkers.td lib/StaticAnalyzer/Checkers/DynamicTypePropagation.cpp lib/StaticAnalyzer/Core/CallEvent.cpp lib/StaticAnalyzer/Core/ExprEngineC.cpp lib/StaticAnalyzer/Core/ProgramState.cpp test/Analysis/inlining/InlineObjCInstanceMethod.m test/Analysis/inlining/ObjCDynTypePopagation.m

Jordan Rose jordan_rose at apple.com
Tue Aug 7 12:20:51 PDT 2012


On Aug 6, 2012, at 22:16 , Anna Zaks <ganna at apple.com> wrote:

> What do you mean by counter example? Is it not possible to have an invocation of setWithArray method in which self is NSSet? Or do you mean that in this case you would like to split the path and test both scenarios - one in which self is NSSet and one in which we don't know what it is? 
> 
> 
>> @implementation NSSet
>> + (void)setWithArray:(NSArray *)array {
>> return [[[self alloc] initWithArray:array] autorelease];
>> }
>> @end
>> 
>> NSMutableSet *makeSet(NSArray *array) {
>> return [NSMutableSet setWithArray:array]; // calls +[NSSet setWithArray:], but returns an NSMutableSet.
>> }

If analyzing makeSet and inlining +[NSMutableSet setWithArray:], we have a case where we "know" +[self alloc] will not create an NSSet, and so we won't want to try to inline any NSSet methods that NSMutableSet might override. So I would definitely like to split the path when analyzing +[NSSet setWithArray:] in isolation, and not split the path when inlining it.

All of this is fallout from checking syntactically for the 'self' variable, which really is just a hidden argument like any other.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120807/adf838b4/attachment.html>


More information about the cfe-commits mailing list