]> granicus.if.org Git - clang/commit
[analyzer] Disable all retain count diagnostics on values that come from ivars.
authorJordan Rose <jordan_rose@apple.com>
Mon, 30 Mar 2015 20:18:00 +0000 (20:18 +0000)
committerJordan Rose <jordan_rose@apple.com>
Mon, 30 Mar 2015 20:18:00 +0000 (20:18 +0000)
commit08f11c436e459efb2e5ccff6f0dcca54b566308c
tree631ab31a65fb44e044e95701a7dbef3c322e0748
parent9ad2cb71d0766bac9d089bd206deef149cadbc77
[analyzer] Disable all retain count diagnostics on values that come from ivars.

This is imitating a pre-r228174 state where ivars are not considered tracked by
default, but with the addition that even ivars /with/ retain count information
(e.g. "[_ivar retain]; [ivar _release];") are not being tracked as well. This is
to ensure that we don't regress on values accessed through both properties and
ivars, which is what r228174 was trying to fix.

The issue occurs in code like this:

  [_contentView retain];
  [_contentView removeFromSuperview];
  [self addSubview:_contentView]; // invalidates 'self'
  [_contentView release];

In this case, the call to -addSubview: may change the value of self->_contentView,
and so the analyzer can't be sure that we didn't leak the original _contentView.
This is a correct conservative view of the world, but not a useful one. Until we
have a heuristic that allows us to not consider this a leak, not emitting a
diagnostic is our best bet.

This commit disables all of the ivar-related retain count tests, but does not
remove them to ensure that we don't crash trying to evaluate either valid or
erroneous code. The next commit will add a new test for the example above so
that this commit (and the previous one) can be reverted wholesale when a better
solution is implemented.

Rest of rdar://problem/20335433

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233592 91177308-0d34-0410-b5e6-96231b3b80d8
lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
test/Analysis/properties.m
test/Analysis/retain-release-path-notes.m