| 651f13cea278ec967336033dd032faef0e9fc2ec |
|
24-Apr-2014 |
Stephen Hines <srhines@google.com> |
Updated to Clang 3.5a.
Change-Id: I8127eb568f674c2e72635b639a3295381fe8af82
/external/clang/test/Analysis/objc-for.m
|
| 219103d76a10b35b5a1e8d2b6737cf724a7cfee7 |
|
08-Nov-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Track whether an ObjC for-in loop had zero iterations.
An Objective-C for-in loop will have zero iterations if the collection is
empty. Previously, we could only detect this case if the program asked for
the collection's -count /before/ the for-in loop. Now, the analyzer
distinguishes for-in loops that had zero iterations from those with at
least one, and can use this information to constrain the result of calling
-count after the loop.
In order to make this actually useful, teach the checker that methods on
NSArray, NSDictionary, and the other immutable collection classes don't
change the count.
<rdar://problem/14992886>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194235 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/objc-for.m
|
| 2ffcd18b845d4f855074ff7011c46e20616e08fd |
|
22-Jun-2013 |
Anna Zaks <ganna@apple.com> |
[analyzer] Use output form collections’ count to decide if ObjC for loop should be entered
This fixes false positives by allowing us to know that a loop is always entered if
the collection count method returns a positive value and vice versa.
Addresses radar://14169391.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184618 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/objc-for.m
|
| 5d2e4e1f9ed87ea26295e891acf7e5a3b106f194 |
|
26-Apr-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] An ObjC for-in loop runs 0 times if the collection is nil.
In an Objective-C for-in loop "for (id element in collection) {}", the loop
will run 0 times if the collection is nil. This is because the for-in loop
is implemented using a protocol method that returns 0 when there are no
elements to iterate, and messages to nil will result in a 0 return value.
At some point we may want to actually model this message send, but for now
we may as well get the nil case correct, and avoid the false positives that
would come with this case.
<rdar://problem/13744632>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180639 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/objc-for.m
|
| dc32de2d92fe4e68e44406ee9667265103fb89bf |
|
26-Sep-2012 |
Nico Weber <nicolasweber@gmx.de> |
Fix two more tests that didn't do anything.
Found with
find test -type f | xargs grep RUN: | grep '%clang' | grep -iv '%s' | grep -v '%t' | grep -v '\\$'
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164678 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/objc-for.m
|
| 1895a0a6936001374f66adbdfcf8abe5edf912ea |
|
11-Jun-2012 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Add ObjCLoopChecker: objects from NSArray et al are non-nil.
While collections containing nil elements can still be iterated over in an
Objective-C for-in loop, the most common Cocoa collections -- NSArray,
NSDictionary, and NSSet -- cannot contain nil elements. This checker adds
that assumption to the analyzer state.
This was the cause of some minor false positives concerning CFRelease calls
on objects in an NSArray.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158319 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/objc-for.m
|