Treat a _Nonnull ivar that is nil as an invariant violation in a similar
fashion to how a nil _Nonnull parameter is treated as a precondition violation.
This avoids warning on defensive returns of nil on defensive internal
checks, such as the following common idiom:
@class InternalImplementation
@interface PublicClass {
InternalImplementation * _Nonnull _internal;
}
-(id _Nonnull)foo;
@end
@implementation PublicClass
-(id _Nonnull)foo {
if (!_internal)
return nil; // no-warning
return [_internal foo];
}
@end
rdar://problem/24485171
llvm-svn: 266157
The nullability checker can sometimes miss detecting nullability precondition
violations in inlined functions because the binding for the parameter
that violated the precondition becomes dead before the return:
int * _Nonnull callee(int * _Nonnull p2) {
if (!p2)
// p2 becomes dead here, so binding removed.
return 0; // warning here because value stored in p2 is symbolic.
else
return p2;
}
int *caller(int * _Nonnull p1) {
return callee(p1);
}
The fix, which is quite blunt, is to not warn about null returns in inlined
methods/functions. This won’t lose much coverage for ObjC because the analyzer
always analyzes each ObjC method at the top level in addition to inlined. It
*will* lose coverage for C — but there aren’t that many codebases with C
nullability annotations.
rdar://problem/25615050
llvm-svn: 266109
Don't emit a path note marking the return site if the return statement does not
have a valid location. This fixes an assertion failure I introduced in r265839.
llvm-svn: 266031
Teach trackNullOrUndefValue() how to look through PseudoObjectExprs to find
the underlying method call for property getters. This makes over-suppression
of 'return nil' in getters consistent with the similar over-suppression for
method and function calls.
rdar://problem/24437252
llvm-svn: 265839
In ObjCMethodCall:getRuntimeDefinition(), if the method is an accessor in a
category, and it doesn't have a self declaration, first try to find the method
in a class extension. This works around a bug in Sema where multiple accessors
are synthesized for properties in class extensions that are redeclared in a
category. The implicit parameters are not filled in for the method on the
category, which causes a crash when trying to synthesize a getter for the
property in BodyFarm. The Sema bug is tracked as rdar://problem/25481164.
rdar://problem/25056531
llvm-svn: 265103
Change body autosynthesis to use the BodyFarm-synthesized body even when
an actual body exists. This enables the analyzer to use the simpler,
analyzer-provided body to model the behavior of the function rather than trying
to understand the actual body. Further, this makes the analyzer robust against
changes in headers that expose the implementations of those bodies.
rdar://problem/25145950
llvm-svn: 264687
Change the nullability checker to not warn along paths where null is returned from
a method with a non-null return type, even when the diagnostic for this return
has been suppressed. This prevents warning from methods with non-null return types
that inline methods that themselves return nil but that suppressed the diagnostic.
Also change the PreconditionViolated state component to be called "InvariantViolated"
because it is set when a post-condition is violated, as well.
rdar://problem/25393539
llvm-svn: 264647
The -dealloc method in CIFilter is highly unusual in that it will release
instance variables belonging to its *subclasses* if the variable name
starts with "input" or backs a property whose name starts with "input".
Subclasses should not release these ivars in their own -dealloc method --
doing so could result in an over release.
Before this commit, the DeallocChecker would warn about missing releases for
such "input" properties -- which could cause users of the analyzer to add
over releases to silence the warning.
To avoid this, DeallocChecker now treats CIFilter "input-prefixed" ivars
as MustNotReleaseDirectly and so will not require a release. Further, it
will now warn when such an ivar is directly released in -dealloc.
rdar://problem/25364901
llvm-svn: 264463
Add the wide character strdup variants (wcsdup, _wcsdup) and the MSVC
version of alloca (_alloca) and other differently named function used
by the Malloc checker.
A patch by Alexander Riccio!
Differential Revision: http://reviews.llvm.org/D17688
llvm-svn: 262894
exactly the same as clang's existing [[clang::fallthrough]] attribute, which
has been updated to have the same semantics. The one significant difference
is that [[fallthrough]] is ill-formed if it's not used immediately before a
switch label (even when -Wimplicit-fallthrough is disabled). To support that,
we now build a CFG of any function that uses a '[[fallthrough]];' statement
to check.
In passing, fix some bugs with our support for statement attributes -- in
particular, diagnose their use on declarations, rather than asserting.
llvm-svn: 262881
Add an -analyzer-config 'nullability:NoDiagnoseCallsToSystemHeaders' option to
the nullability checker. When enabled, this option causes the analyzer to not
report about passing null/nullable values to functions and methods declared
in system headers.
This option is motivated by the observation that large projects may have many
nullability warnings. These projects may find warnings about nullability
annotations that they have explicitly added themselves higher priority to fix
than warnings on calls to system libraries.
llvm-svn: 262763
In dealloc methods, the analyzer now warns when -dealloc is called directly on
a synthesized retain/copy ivar instead of -release. This is intended to find mistakes of
the form:
- (void)dealloc {
[_ivar dealloc]; // Mistaken call to -dealloc instead of -release
[super dealloc];
}
rdar://problem/16227989
llvm-svn: 262729
This prevents false negatives when a -dealloc method, for example, removes itself as
as an observer with [[NSNotificationCenter defaultCenter] removeObserver:self]. It is
unlikely that passing 'self' to a system header method will release 'self''s instance
variables, so this is unlikely to produce false positives.
A challenge here is that while CheckObjCDealloc no longer treats these calls as
escaping, the rest of the analyzer still does. In particular, this means that loads
from the same instance variable before and after a call to a system header will
result in different symbols being loaded by the region store. To account for this,
the checker now treats different ivar symbols with the same instance and ivar decl as
the same for the purpose of release checking and more eagerly removes a release
requirement when an instance variable is assumed to be nil. This was not needed before
because when an ivar escaped its release requirement was always removed -- now the
requirement is not removed for calls to system headers.
llvm-svn: 262261
Change "use of 'self' after it has been freed with call to [super dealloc]" to
"use of 'self' after it has been deallocated" and "use of instance variable
'_ivar' after the instance has been freed with call to [super dealloc]" to
"use of instance variable '_ivar' after 'self' has been deallocated".
llvm-svn: 261945
Referring to 'self' after a call to [super dealloc] is a use-after-free in
Objective-C because NSObject's -dealloc frees the memory pointed to by self.
This patch extends the ObjCSuperDeallocChecker to catch this error.
rdar://problem/6953275
Differential Revision: http://reviews.llvm.org/D17528
llvm-svn: 261935
This reapplies "[analyzer] Make ObjCDeallocChecker path sensitive." (r261917)
with a fix for an error on some bots about specializing a template
from another namespace.
llvm-svn: 261929
Convert the ObjCDeallocChecker to be path sensitive. The primary
motivation for this change is to prevent false positives when -dealloc calls
helper invalidation methods to release instance variables, but it additionally
improves precision when -dealloc contains control flow. It also reduces the need
for pattern matching. The check for missing -dealloc methods remains AST-based.
Part of rdar://problem/6927496
Differential Revision: http://reviews.llvm.org/D17511
llvm-svn: 261917
When looking up the 'self' decl in block captures, make sure to find the actual
self declaration even when the block captures a local variable named 'self'.
rdar://problem/24751280
llvm-svn: 261703
This patch is intended to improve pointer arithmetic checker.
From now on it only warns when the pointer arithmetic is likely to cause an
error. For example when the pointer points to a single object, or an array of
derived types.
Differential Revision: http://reviews.llvm.org/D14203
llvm-svn: 261632
Add an alpha path checker that warns about duplicate calls to [super dealloc].
This will form the foundation of a checker that will detect uses of
'self' after calling [super dealloc].
Part of rdar://problem/6953275.
Based on a patch by David Kilzer!
Differential Revision: http://reviews.llvm.org/D5238
llvm-svn: 261545
Add a checker callback that is called when the analyzer starts analyzing a
function either at the top level or when inlined. This will be used by a
follow-on patch making the DeallocChecker path sensitive.
Differential Revision: http://reviews.llvm.org/D17418
llvm-svn: 261293
When modeling a call to a setter for a property that is synthesized to be
backed by an instance variable, don't invalidate the entire instance
but rather only the storage for the updated instance variable itself.
This still doesn't model the effect of the setter completely. It doesn't
bind the set value to the ivar storage location because doing so would cause
the set value to escape, removing valuable diagnostics about potential
leaks of the value from the retain count checker.
llvm-svn: 261243
Look through PseudoObjectExpr and OpaqueValueExprs when scanning for
release-like operations. This commit also adds additional tests in anticipation
of re-writing this as a path-sensitive checker.
llvm-svn: 260608
Now that the libcpp implementations of these methods has a branch that doesn't call
memmove(), the analyzer needs to invalidate the destination for these methods explicitly.
rdar://problem/23575656
llvm-svn: 260043
It is common for the ivars for read-only assign properties to always be stored retained,
so don't warn for a release in dealloc for the ivar backing these properties.
llvm-svn: 259998
If the class or method name case-insensitively contains the term "debug",
suppress warnings about string constants flowing to user-facing UI APIs.
llvm-svn: 259875
-analyzer-display progress option prints only function names which may be ambiguous. This patch forces AnalysisConsumer to print fully-qualified function names.
Patch by Alex Sidorin!
Differential Revision: http://reviews.llvm.org/D16804
llvm-svn: 259646
Avoids unexpected overflows while performing pointer arithmetics in 64-bit code.
Moreover, neither PointerDiffType nor 'int' can be used as a common array index
type because arrays may have size (and indexes) more than PTRDIFF_MAX but less
than SIZE_MAX.
Patch by Aleksei Sidorin!
Differential Revision: http://reviews.llvm.org/D16063
llvm-svn: 259345
We already do this for case splits introduced as a result of defensive null
checks in functions and methods, so do the same for function-like macros.
rdar://problem/19640441
llvm-svn: 259222
- Include the position of the argument on which the nullability is violated
- Differentiate between a 'method' and a 'function' in the message wording
- Test for the error message text in the tests
- Fix a bug with setting 'IsDirectDereference' which resulted in regular dereferences assumed to have call context.
llvm-svn: 259221
There are multiple, common idioms of defensive nil-checks in copy,
mutableCopy, and init methods in ObjC. The analyzer doesn't currently have the
capability to distinguish these idioms from true positives, so suppress all
warnings about returns in those families. This is a pretty blunt suppression
that we should improve later.
rdar://problem/24395811
llvm-svn: 259099
Previously the ObjC Dealloc Checker only checked classes with ivars, not
retained properties, which caused three bugs:
- False positive warnings about a missing -dealloc method in classes with only
ivars.
- Missing warnings about a missing -dealloc method on classes with only
properties.
- Missing warnings about an over-released or under-released ivar associated with
a retained property in classes with only properties.
The fix is to check only classes with at least one retained synthesized
property.
This also exposed a bug when reporting an over-released or under-released
property that did not contain a synthesize statement. The checker tried to
associate the warning with an @synthesize statement that did not exist, which
caused an assertion failure in debug builds. The fix is to fall back to the
@property statement in this case.
A patch by David Kilzer!
Part of rdar://problem/6927496
Differential Revision: http://reviews.llvm.org/D5023
llvm-svn: 258896
After r251874, readonly properties that are shadowed by a readwrite property
in a class extension no longer have an instance variable, which caused the body
farm to not synthesize getters. Now, if a readonly property does not have an
instance variable look for a shadowing property and try to get the instance
variable from there.
rdar://problem/24060091
llvm-svn: 258886
A common idiom in Objective-C initializers is for a defensive nil-check on the
result of a call to a super initializer:
if (self = [super init]) {
...
}
return self;
To avoid warning on this idiom, the nullability checker now suppress diagnostics
for returns of nil on syntactic 'return self' even in initializers with non-null
return types.
llvm-svn: 258461
In r256567 I changed the nullability checker to suppress warnings about returning a null
value from a function/method with a non-null return type when the type of the returned
expression is itself nonnull. This enables the programmer to silence nullability warnings
by casting to _Nonnull:
return (SomeObject * _Nonnull)nil;
Unfortunately, under ObjC automated reference counting, Sema adds implicit casts to
_Nonnull to return expressions of nullable or unspecified types in functions with
non-null function/method return types. With r256567, these casts cause all nullability
warnings for returns of reference-counted types to be suppressed under ARC, leading to
false negatives.
This commit updates the nullability checker to look through implicit casts before
determining the type of the returned expression. It also updates the tests to turn on
ARC for the nullability_nullonly.mm testfile and adds a new testfile to test when ARC
is turned off.
rdar://problem/24200117
llvm-svn: 258061
Make sure that we do not add SymbolCast at the very boundary of
the range in which the cast would not certainly happen.
Differential Revision: http://reviews.llvm.org/D16178
llvm-svn: 258039
Update NullabilityChecker so that it checks return statements in ObjC methods.
Previously it was returning early because methods do not have a function type.
Also update detection of violated parameter _Nonnull preconditions to handle
ObjC methods.
rdar://problem/24200560
llvm-svn: 257938
Provide separate visitor templates for the three hierarchies, and also
the `FullSValVisitor' class, which is a union of all three visitors.
Additionally, add a particular example visitor, `SValExplainer', in order to
test the visitor templates. This visitor is capable of explaining the SVal,
SymExpr, or MemRegion in a natural language.
Compared to the reverted r257605, this fixes the test that used to fail
on some triples, and fixes build failure under -fmodules.
Differential Revision: http://reviews.llvm.org/D15448
llvm-svn: 257893
This reverts commit r257605.
The test fails on architectures that use unsigned int as size_t.
SymbolManager.h fails with compile errors on some platforms.
llvm-svn: 257608
Provide separate visitor templates for the three hierarchies, and also
the `FullSValVisitor' class, which is a union of all three visitors.
Additionally, add a particular example visitor, `SValExplainer', in order to
test the visitor templates. This visitor is capable of explaining the SVal,
SymExpr, or MemRegion in a natural language.
Differential Revision: http://reviews.llvm.org/D15448
llvm-svn: 257605
This fix a bug in RangeSet::pin causing single value ranges to be considered non conventionally ordered.
Differential Revision: http://reviews.llvm.org/D12901
llvm-svn: 257467
The current workaround for truncations not being modelled is that the evaluation of integer to integer casts are simply bypassed and so the original symbol is used as the new casted symbol (cf SimpleSValBuilder::evalCastFromNonLoc).
This lead to the issue described in PR25078, as the RangeConstraintManager associates ranges with symbols.
The new evalIntegralCast method added by this patch wont bypass the cast if it finds the range of the symbol to be greater than the maximum value of the target type.
The fix to RangeSet::pin mentioned in the initial review will be committed separately.
Differential Revision: http://reviews.llvm.org/D12901
llvm-svn: 257464
visited decls.
Due to redeclarations, the function may have different declarations used
in CallExpr and in the definition. However, we need to use a unique
declaration for both store and lookup in VisitedCallees. This patch
fixes issues with analysis in topological order. A simple test is
included.
Patch by Alex Sidorin!
Differential Revision: http://reviews.llvm.org/D15410
llvm-svn: 257318
The analyzer reports a shift by a negative value in the constructor. The bug can
be easily triggered by calling std::random_shuffle on a vector
(<rdar://problem/19658126>).
(The shift by a negative value is reported because __w0_ gets constrained to
63 by the conditions along the path:__w0_ < _WDt && __w0_ >= _WDt-1,
where _WDt is 64. In normal execution, __w0_ is not 63, it is 1 and there is
no overflow. The path is infeasible, but the analyzer does not know about that.)
llvm-svn: 256886
Android's assert can call both the __assert and __assert2 functions under the cover, but
the NoReturnFunctionChecker does not handle the latter. This commit fixes that.
A patch by Yury Gribov!
Differential Revision: http://reviews.llvm.org/D15810
llvm-svn: 256605
Prevent the analyzer from warning when a _Nonnnull local variable is implicitly
zero-initialized because of Objective-C automated reference counting. This avoids false
positives in cases where a _Nonnull local variable cannot be initialized with an
initialization expression, such as:
NSString * _Nonnull s; // no-warning
@autoreleasepool {
s = ...;
}
The nullability checker will still warn when a _Nonnull local variable is explicitly
initialized with nil.
This suppression introduces the potential for false negatives if the local variable
is used before it is assigned a _Nonnull value. Based on a discussion with Anna Zaks,
Jordan Rose, and John McCall, I've added a FIXME to treat implicitly zero-initialized
_Nonnull locals as uninitialized in Sema's UninitializedValues analysis to avoid these
false negatives.
rdar://problem/23522311
llvm-svn: 256603
The nullability checker currently allows casts to suppress warnings when a nil
literal is passed as an argument to a parameter annotated as _Nonnull:
foo((NSString * _Nonnull)nil); // no-warning
It does so by suppressing the diagnostic when the *type* of the argument expression
is _Nonnull -- even when the symbolic value returned is known to be nil.
This commit updates the nullability checker to similarly honor such casts in the analogous
scenario when nil is returned from a function with a _Nonnull return type:
return (NSString * _Nonnull)nil; // no-warning
This commit also normalizes variable naming between the parameter and return cases and
adds several tests demonstrating the limitations of this suppression mechanism (such as
when nil is cast to _Nonnull and then stored into a local variable without a nullability
qualifier). These tests are marked with FIXMEs.
rdar://problem/23176782
llvm-svn: 256567
When the analyzer evaluates a CXXConstructExpr, it looks ahead in the CFG for
the current block to detect what region the object should be constructed into.
If the constructor was directly constructed into a local variable or field
region then there is no need to explicitly bind the constructed value to
the local or field when analyzing the DeclStmt or CXXCtorInitializer that
called the constructor.
Unfortunately, there were situations in which the CXXConstructExpr was
constructed into a temporary region but when evaluating the corresponding
DeclStmt or CXXCtorInitializer the analyzer assumed the object was constructed
into the local or field. This led to spurious warnings about uninitialized
values (PR25777).
To avoid these false positives, this commit factors out the logic for
determining when a CXXConstructExpr will be directly constructed into existing
storage, adds the inverse logic to detect when the corresponding later bind can
be safely skipped, and adds assertions to make sure these two checks are in
sync.
rdar://problem/21947725
llvm-svn: 255859
error: 'warning' diagnostics expected but not seen:
File clang/test/Analysis/padding_c.c Line 194 (directive at clang/test/Analysis/padding_c.c:193): Excessive padding in 'struct DefaultAttrAlign'
1 error generated.
llvm-svn: 255636
The intent of this checker is to generate a report for any class / structure
that could reduce its padding by reordering the fields. This results in a very
noisy checker. To reduce the noise, this checker will currently only warn when
the number of bytes over "optimal" is more than 24. This value is configurable
with -analyzer-config performance.Padding:AllowedPad=N. Small values of
AllowedPad have the potential to generate hundreds of reports, and gigabytes
of HTML reports.
The checker searches for padding violations in two main ways. First, it goes
record by record. A report is generated if the fields could be reordered in a
way that reduces the padding by more than AllowedPad bytes. Second, the
checker will generate a report if an array will cause more than AllowedPad
padding bytes to be generated.
The record checker currently skips many ABI specific cases. Classes with base
classes are skipped because base class tail padding is ABI specific. Bitfields
are just plain hard, and duplicating that code seems like a bad idea. VLAs are
both uncommon and non-trivial to fix.
The array checker isn't very thorough right now. It only checks to see if the
element type's fields could be reordered, and it doesn't recursively check to
see if any of the fields' fields could be reordered. At some point in the
future, it would be nice if "arrays" could also look at array new usages and
malloc patterns that appear to be creating arrays.
llvm-svn: 255545
SymbolReaper was destroying the symbol too early when it was referenced only
from an index SVal of a live ElementRegion.
In order to test certain aspects of this patch, extend the debug.ExprInspection
checker to allow testing SymbolReaper in a direct manner.
Differential Revision: http://reviews.llvm.org/D12726
llvm-svn: 255236
When a C++ lambda captures a variable-length array, it creates a capture
field to store the size of the array. The initialization expression for this
capture is null, which led the analyzer to crash when initializing the field.
To avoid this, use the size expression from the VLA type to determine the
initialization value.
rdar://problem/23748072
llvm-svn: 254962
This commit prevents MemRegion::getAsOffset() from crashing when the analyzed
program casts a symbolic region of a non-record type to some derived type and
then attempts to access a field of the base type.
rdar://problem/23458069
llvm-svn: 254806
clang converts C++ lambdas to blocks with an implicit user-defined conversion
operator method on the lambda record. This method returns a block that captures a copy
of the lambda. To inline a lambda-converted block, the analyzer now calls the lambda
records's call operator method on the lambda captured by the block.
llvm-svn: 254702
Don't warn about addresses of stack-allocated blocks escaping if the block
region was cast with CK_CopyAndAutoreleaseBlockObject. These casts, which
are introduced in the implicit conversion operator for lambda-to-block
conversions, cause the block to be copied to the heap -- so the warning is
spurious.
llvm-svn: 254639
Add tests demonstrating that the analyzer supports generalized lambda capture. This
support falls out naturally from the work Gábor Horváth did adding C++11 lambdas to
the analyzer.
llvm-svn: 254114
This prevents spurious dead store warnings when a C++ lambda is casted to a block.
I've also added several tests documenting our still-incomplete support for lambda-to-block
casts.
rdar://problem/22236293
llvm-svn: 254107
The nullability checker was not suppressing false positives resulting from
inlined defensive checks when null was bound to a nonnull variable because it
was passing the entire bind statement rather than the value expression to
trackNullOrUndefValue().
This commit changes that checker to synactically match on the bind statement to
extract the value expression so it can be passed to trackNullOrUndefValue().
rdar://problem/23575439
llvm-svn: 254007
The analyzer currently reports dead store false positives when a local variable
is captured by reference in a C++ lambda.
For example:
int local = 0; auto lambda = [&local]() {
local++;
};
local = 7; // False Positive: Value stored to 'local' is never read
lambda();
In this case, the assignment setting `local` to 7 is not a dead store because
the called lambda will later read that assigned value.
This commit silences this source of false positives by treating locals captured
by reference in C++ lambdas as escaped, similarly to how the DeadStoresChecker
deals with locals whose address is taken.
rdar://problem/22165179
llvm-svn: 253630
Conversions between unrelated pointer types (e.g. char * and void *) involve
bitcasts which were not properly modeled in case of static initializers. The
patch fixes this problem.
The problem was originally spotted by Artem Dergachev. Patched by Yuri Gribov!
Differential Revision: http://reviews.llvm.org/D14652
llvm-svn: 253532
Since we don't check functions in dependent contexts, we should skip blocks
in those contexts as well. This avoids an assertion failure when the
DeadStoresChecker attempts to evaluate an array subscript expression with
a dependent name type.
rdar://problem/23564220
llvm-svn: 253516
When calling a ObjC method on super from inside a C++ lambda, look at the
captures to find "self". This mirrors how the analyzer handles calling super in
an ObjC block and fixes an assertion failure.
rdar://problem/23550077
llvm-svn: 253176
The analyzer incorrectly treats captures as references if either the original
captured variable is a reference or the variable is captured by reference.
This causes the analyzer to crash when capturing a reference type by copy
(PR24914). Fix this by refering solely to the capture field to determine when a
DeclRefExpr for a lambda capture should be treated as a reference type.
https://llvm.org/bugs/show_bug.cgi?id=24914
rdar://problem/23524412
llvm-svn: 253157
Summary:
VisitReturnStmt would create a new block with including Dtors, so the Dtors created
in VisitCompoundStmts would be in an unreachable block.
Example:
struct S {
~S();
};
void f()
{
S s;
return;
}
void g()
{
S s;
}
Before this patch, f has one additional unreachable block containing just the
destructor of S. With this patch, both f and g have the same blocks.
Reviewers: krememek
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D13973
llvm-svn: 253107
Function__builtin_signbit returns wrong value for type ppcf128 on big endian
machines. This patch fixes how value is generated in that case.
Patch by Aleksandar Beserminji.
Differential Revision: http://reviews.llvm.org/D14149
llvm-svn: 252307
This checker looks for unsafe constructs in vforked process:
function calls (excluding whitelist), memory write and returns.
This was originally motivated by a vfork-related bug in xtables package.
Patch by Yury Gribov.
Differential revision: http://reviews.llvm.org/D14014
llvm-svn: 252285
Update RegionStoreManager::getBinding() to return UnknownVal when trying to get
the binding for a BlockDataRegion. Previously, getBinding() would try to cast the
BlockDataRegion to a TypedValueRegion and crash. This happened when a block
was passed as a parameter to an inlined function for which
StackHintGeneratorForSymbol::getMessage() tried to generate a stack hint message.
rdar://problem/21291971
llvm-svn: 252185
This commit creates a new 'optin' top-level checker package and moves several of
the localizability checkers into it.
This package is for checkers that are not alpha and that would normally be on by
default but where the driver does not have enough information to determine when
they are applicable. The localizability checkers fit this criterion because the
driver cannot determine whether a project is localized or not -- this is best
determined at the IDE or build-system level.
This new package is *not* intended for checkers that are too noisy to be on by
default.
The hierarchy under 'optin' mirrors that in 'alpha': checkers under 'optin'
should be organized in the hierarchy they would have had if they were truly top
level (e.g., optin.osx.cocoa.MyOptInChecker).
Differential Revision: http://reviews.llvm.org/D14303
llvm-svn: 252080
Summary:
Dear All,
We have been looking at the following problem, where any code after the constant bound loop is not analyzed because of the limit on how many times the same block is visited, as described in bugzillas #7638 and #23438. This problem is of interest to us because we have identified significant bugs that the checkers are not locating. We have been discussing a solution involving ranges as a longer term project, but I would like to propose a patch to improve the current implementation.
Example issue:
```
for (int i = 0; i < 1000; ++i) {...something...}
int *p = 0;
*p = 0xDEADBEEF;
```
The proposal is to go through the first and last iterations of the loop. The patch creates an exploded node for the approximate last iteration of constant bound loops, before the max loop limit / block visit limit is reached. It does this by identifying the variable in the loop condition and finding the value which is “one away” from the loop being false. For example, if the condition is (x < 10), then an exploded node is created where the value of x is 9. Evaluating the loop body with x = 9 will then result in the analysis continuing after the loop, providing x is incremented.
The patch passes all the tests, with some modifications to coverage.c, in order to make the ‘function_which_gives_up’ continue to give up, since the changes allowed the analysis to progress past the loop.
This patch does introduce possible false positives, as a result of not knowing the state of variables which might be modified in the loop. I believe that, as a user, I would rather have false positives after loops than do no analysis at all. I understand this may not be the common opinion and am interested in hearing your views. There are also issues regarding break statements, which are not considered. A more advanced implementation of this approach might be able to consider other conditions in the loop, which would allow paths leading to breaks to be analyzed.
Lastly, I have performed a study on large code bases and I think there is little benefit in having “max-loop” default to 4 with the patch. For variable bound loops this tends to result in duplicated analysis after the loop, and it makes little difference to any constant bound loop which will do more than a few iterations. It might be beneficial to lower the default to 2, especially for the shallow analysis setting.
Please let me know your opinions on this approach to processing constant bound loops and the patch itself.
Regards,
Sean Eveson
SN Systems - Sony Computer Entertainment Group
Reviewers: jordan_rose, krememek, xazax.hun, zaks.anna, dcoughlin
Subscribers: krememek, xazax.hun, cfe-commits
Differential Revision: http://reviews.llvm.org/D12358
llvm-svn: 251621
The analyzer assumes that system functions will not free memory or modify the
arguments in other ways, so we assume that arguments do not escape when
those are called. However, this may lead to false positive leak errors. For
example, in code like this where the pointers added to the rb_tree are freed
later on:
struct alarm_event *e = calloc(1, sizeof(*e));
<snip>
rb_tree_insert_node(&alarm_tree, e);
Add a heuristic to assume that calls to system functions taking void*
arguments allow for pointer escape.
llvm-svn: 251449
This patch adds hashes to the plist and html output to be able to identfy bugs
for suppressing false positives or diff results against a baseline. This hash
aims to be resilient for code evolution and is usable to identify bugs in two
different snapshots of the same software. One missing piece however is a
permanent unique identifier of the checker that produces the warning. Once that
issue is resolved, the hashes generated are going to change. Until that point
this feature is marked experimental, but it is suitable for early adoption.
Differential Revision: http://reviews.llvm.org/D10305
Original patch by: Bence Babati!
llvm-svn: 251011
Prevent invalidation of `this' when a method is const; fixing PR 21606.
A patch by Sean Eveson!
Differential Revision: http://reviews.llvm.org/D13099
llvm-svn: 250237
These test updates almost exclusively around the change in behavior
around enum: enums without a definition are considered incomplete except
when targeting MSVC ABIs. Since these tests are interested in the
'incomplete-enum' behavior, restrict them to %itanium_abi_triple.
llvm-svn: 249660
Change the analyzer's modeling of memcpy to be more precise when copying into fixed-size
array fields. With this change, instead of invalidating the entire containing region the
analyzer now invalidates only offsets for the array itself when it can show that the
memcpy stays within the bounds of the array.
This addresses false positive memory leak warnings of the kind reported by
krzysztof in https://llvm.org/bugs/show_bug.cgi?id=22954
(This is the second attempt, now with assertion failures resolved.)
A patch by Pierre Gousseau!
Differential Revision: http://reviews.llvm.org/D12571
llvm-svn: 248516
This patch ignores malloc-overflow bug in two cases:
Case1:
x = a/b; where n < b
malloc (x*n); Then x*n will not overflow.
Case2:
x = a; // when 'a' is a known value.
malloc (x*n);
Also replaced isa with dyn_cast.
Reject multiplication by zero cases in MallocOverflowSecurityChecker
Currently MallocOverflowSecurityChecker does not catch cases like:
malloc(n * 0 * sizeof(int));
This patch rejects such cases.
Two test cases added. malloc-overflow2.c has an example inspired from a code
in linux kernel where the current checker flags a warning while it should not.
A patch by Aditya Kumar!
Differential Revision: http://reviews.llvm.org/D9924
llvm-svn: 248446
Various improvements to the localization checker:
* Adjusted copy to be consistent with diagnostic text in other Apple
API checkers.
* Added in ~150 UIKit / AppKit methods that require localized strings in
UnlocalizedStringsChecker.
* UnlocalizedStringChecker now checks for UI methods up the class hierarchy and
UI methods that conform for a certain Objective-C protocol.
* Added in alpha version of PluralMisuseChecker and some regression tests. False
positives are still not ideal.
(This is the second attempt, with the memory issues on Linux resolved.)
A patch by Kulpreet Chilana!
Differential Revision: http://reviews.llvm.org/D12417
llvm-svn: 248432
Various improvements to the localization checker:
* Adjusted copy to be consistent with diagnostic text in other Apple
API checkers.
* Added in ~150 UIKit / AppKit methods that require localized strings in
UnlocalizedStringsChecker.
* UnlocalizedStringChecker now checks for UI methods up the class hierarchy and
UI methods that conform for a certain Objective-C protocol.
* Added in alpha version of PluralMisuseChecker and some regression tests. False
positives are still not ideal.
A patch by Kulpreet Chilana!
Differential Revision: http://reviews.llvm.org/D12417
llvm-svn: 248350
Currently realloc(ptr, 0) is treated as free() which seems to be not correct. C
standard (N1570) establishes equivalent behavior for malloc(0) and realloc(ptr,
0): "7.22.3 Memory management functions calloc, malloc, realloc: If the size of
the space requested is zero, the behavior is implementation-defined: either a
null pointer is returned, or the behavior is as if the size were some nonzero
value, except that the returned pointer shall not be used to access an object."
The patch equalizes the processing of malloc(0) and realloc(ptr,0). The patch
also enables unix.Malloc checker to detect references to zero-allocated memory
returned by realloc(ptr,0) ("Use of zero-allocated memory" warning).
A patch by Антон Ярцев!
Differential Revision: http://reviews.llvm.org/D9040
llvm-svn: 248336
This fixes PR16833, in which the analyzer was using large amounts of memory
for switch statements with large case ranges.
rdar://problem/14685772
A patch by Aleksei Sidorin!
Differential Revision: http://reviews.llvm.org/D5102
llvm-svn: 248318
Summary:
`TypeTraitExpr`s are not supported by the ExprEngine today. Analyzer
creates a sink, and aborts the block. Therefore, certain bugs that
involve type traits intrinsics cannot be detected (see PR24710).
This patch creates boolean `SVal`s for `TypeTraitExpr`s, which are
evaluated by the compiler.
Test within the patch is a summary of PR24710.
Reviewers: zaks.anna, dcoughlin, krememek
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D12482
llvm-svn: 248314
Summary:
Name `Out` refers to the parameter. It is moved into the member `Out`
in ctor-init. Dereferencing null pointer will crash clang, if user
passes '-analyzer-viz-egraph-ubigraph' argument.
Reviewers: zaks.anna, krememek
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D12119
llvm-svn: 248050
The analyzer trims unnecessary nodes from the exploded graph before reporting
path diagnostics. However, in some cases it can trim all nodes (including the
error node), leading to an assertion failure (see
https://llvm.org/bugs/show_bug.cgi?id=24184).
This commit addresses the issue by adding two new APIs to CheckerContext to
explicitly create error nodes. Unless the client provides a custom tag, these
APIs tag the node with the checker's tag -- preventing it from being trimmed.
The generateErrorNode() method creates a sink error node, while
generateNonFatalErrorNode() creates an error node for a path that should
continue being explored.
The intent is that one of these two methods should be used whenever a checker
creates an error node.
This commit updates the checkers to use these APIs. These APIs
(unlike addTransition() and generateSink()) do not take an explicit Pred node.
This is because there are not any error nodes in the checkers that were created
with an explicit different than the default (the CheckerContext's Pred node).
It also changes generateSink() to require state and pred nodes (previously
these were optional) to reduce confusion.
Additionally, there were several cases where checkers did check whether a
generated node could be null; we now explicitly check for null in these places.
This commit also includes a test case written by Ying Yi as part of
http://reviews.llvm.org/D12163 (that patch originally addressed this issue but
was reverted because it introduced false positive regressions).
Differential Revision: http://reviews.llvm.org/D12780
llvm-svn: 247859
In Objective-C, method calls with nil receivers are essentially no-ops. They
do not fault (although the returned value may be garbage depending on the
declared return type and architecture). Programmers are aware of this
behavior and will complain about a false alarm when the analyzer
diagnoses API violations for method calls when the receiver is known to
be nil.
Rather than require each individual checker to be aware of this behavior
and suppress a warning when the receiver is nil, this commit
changes ExprEngineObjC so that VisitObjCMessage skips calling checker
pre/post handlers when the receiver is definitely nil. Instead, it adds a
new event, ObjCMessageNil, that is only called in that case.
The CallAndMessageChecker explicitly cares about this case, so I've changed it
to add a callback for ObjCMessageNil and moved the logic in PreObjCMessage
that handles nil receivers to the new callback.
rdar://problem/18092611
Differential Revision: http://reviews.llvm.org/D12123
llvm-svn: 247653
Add an option (-analyzer-config min-blocks-for-inline-large=14) to control the function
size the inliner considers as large, in relation to "max-times-inline-large". The option
defaults to the original hard coded behaviour, which I believe should be adjustable with
the other inlining settings.
The analyzer-config test has been modified so that the analyzer will reach the
getMinBlocksForInlineLarge() method and store the result in the ConfigTable, to ensure it
is dumped by the debug checker.
A patch by Sean Eveson!
Differential Revision: http://reviews.llvm.org/D12406
llvm-svn: 247463
This is making our internal build bot fail because it results in extra warnings being
emitted past what should be sink nodes. (There is actually an example of this in the
updated malloc.c test in the reverted commit.)
I'm working on a patch to fix the original issue by adding a new checker API to explicitly
create error nodes. This API will ensure that error nodes are always tagged in order to
prevent them from being reclaimed.
This reverts commit r246188.
llvm-svn: 247103
Change the analyzer's modeling of memcpy to be more precise when copying into fixed-size
array fields. With this change, instead of invalidating the entire containing region the
analyzer now invalidates only offsets for the array itself when it can show that the
memcpy stays within the bounds of the array.
This addresses false positive memory leak warnings of the kind reported by
krzysztof in https://llvm.org/bugs/show_bug.cgi?id=22954
A patch by Pierre Gousseau!
Differential Revision: http://reviews.llvm.org/D11832
llvm-svn: 246345
The assertion is caused by reusing a “filler” ExplodedNode as an error node.
The “filler” nodes are only used for intermediate processing and are not
essential for analyzer history, so they can be reclaimed when the
ExplodedGraph is trimmed by the “collectNode” function. When a checker finds a
bug, they generate a new transition in the ExplodedGraph. The analyzer will
try to reuse the existing predecessor node. If it cannot, it creates a new
ExplodedNode, which always has a tag to uniquely identify the creation site.
The assertion is caused when the analyzer reuses a “filler” node.
In the test case, some “filler” nodes were reused and then reclaimed later
when the ExplodedGraph was trimmed. This caused an assertion because the node
was needed to generate the report. The “filler” nodes should not be reused as
error nodes. The patch adds a constraint to prevent this happening, which
solves the problem and makes the test cases pass.
Differential Revision: http://reviews.llvm.org/D11433
Patch by Ying Yi!
llvm-svn: 246188
Add checkers that detect code-level localizability issues for OS X / iOS:
- A path sensitive checker that warns about uses of non-localized
NSStrings passed to UI methods expecting localized strings.
- A syntax checker that warns against not including a comment in
NSLocalizedString macros.
A patch by Kulpreet Chilana!
(This is the second attempt with the compilation issue on Windows and
the random test failures resolved.)
llvm-svn: 245093
This reverts commit fc885033a30b6e30ccf82398ae7c30e646727b10.
Revert all localization checker commits until the proper fix is implemented.
llvm-svn: 244394
Add checkers that detect code-level localizability issues for OS X / iOS:
- A path sensitive checker that warns about uses of non-localized
NSStrings passed to UI methods expecting localized strings.
- A syntax checker that warns against not including a comment in
NSLocalizedString macros.
A patch by Kulpreet Chilana!
llvm-svn: 244389
The ObjCSuperCallChecker issues alarms for various Objective-C APIs that require
a subclass to call to its superclass's version of a method when overriding it.
So, for example, it raises an alarm when the -viewDidLoad method in a subclass
of UIViewController does not call [super viewDidLoad].
This patch fixes a false alarm where the analyzer erroneously required the
implementation of the superclass itself (e.g., UIViewController) to call
super.
rdar://problem/18416944
Differential Revision: http://reviews.llvm.org/D11842
llvm-svn: 244386
BlockDecl has a poor AST representation because it doesn't carry its type
with it. Instead, the containing BlockExpr has the full type. This almost
never matters for the analyzer, but if the block decl contains static
local variables we need to synthesize a region to put them in, and this
region will necessarily not have the right type.
Even /that/ doesn't matter, unless
(1) the block calls the function or method containing the block, and
(2) the value of the block expr is used in some interesting way.
In this case, we actually end up needing the type of the block region,
and it will be set to our synthesized type. It turns out we've been doing
a terrible job faking that type -- it wasn't a block pointer type at all.
This commit fixes that to at least guarantee a block pointer type, using
the signature written by the user if there is one.
This is not really a correct answer because the block region's type will
/still/ be wrong, but further efforts to make this right in the analyzer
would probably be silly. We should just change the AST.
rdar://problem/21698099
llvm-svn: 241944
A patch by Karthik Bhat!
This patch fixes a regression introduced by r224398. Prior to r224398
we were able to analyze the following code in test-include.c and report
a null deref in this case. But post r224398 this analysis is being skipped.
E.g.
// test-include.c
#include "test-include.h"
void test(int * data) {
data = 0;
*data = 1;
}
// test-include.h
void test(int * data);
This patch uses the function body (instead of its declaration) as the location
of the function when deciding if the Decl should be analyzed with path-sensitive
analysis. (Prior to r224398, the call graph was guaranteed to have a definition
when available.)
llvm-svn: 240800
Addresses a conflict with glibc's __nonnull macro by renaming the type
nullability qualifiers as follows:
__nonnull -> _Nonnull
__nullable -> _Nullable
__null_unspecified -> _Null_unspecified
This is the major part of rdar://problem/21530726, but does not yet
provide the Darwin-specific behavior for the old names.
llvm-svn: 240596
That is,
void cf2(CFTypeRef * __nullable p CF_RETURNS_NOT_RETAINED);
is equivalent to
void cf2(CFTypeRef __nullable * __nullable p CF_RETURNS_NOT_RETAINED);
More rdar://problem/18742441
llvm-svn: 240186
Includes a simple static analyzer check and not much else, but we'll also
be able to take advantage of this in Swift.
This feature can be tested for using __has_feature(cf_returns_on_parameters).
This commit also contains two fixes:
- Look through non-typedef sugar when deciding whether something is a CF type.
- When (cf|ns)_returns(_not)?_retained is applied to invalid properties,
refer to "property" instead of "method" in the error message.
rdar://problem/18742441
llvm-svn: 240185
Update ObjCContainersChecker to be notified when pointers escape so it can
remove size information for escaping CFMutableArrayRefs. When such pointers
escape, un-analyzed code could mutate the array and cause the size information
to be incorrect.
rdar://problem/19406485
llvm-svn: 239709
Based on previous discussion on the mailing list, clang currently lacks support
for C99 partial re-initialization behavior:
Reference: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-April/029188.html
Reference: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_253.htm
This patch attempts to fix this problem.
Given the following code snippet,
struct P1 { char x[6]; };
struct LP1 { struct P1 p1; };
struct LP1 l = { .p1 = { "foo" }, .p1.x[2] = 'x' };
// this example is adapted from the example for "struct fred x[]" in DR-253;
// currently clang produces in l: { "\0\0x" },
// whereas gcc 4.8 produces { "fox" };
// with this fix, clang will also produce: { "fox" };
Differential Review: http://reviews.llvm.org/D5789
llvm-svn: 239446
Emit warning when operand to `delete` is allocated with `new[]` or
operand to `delete[]` is allocated with `new`.
rev 2 update:
`getNewExprFromInitListOrExpr` should return `dyn_cast_or_null`
instead of `dyn_cast`, since `E` might be null.
Reviewers: rtrieu, jordan_rose, rsmith
Subscribers: majnemer, cfe-commits
Differential Revision: http://reviews.llvm.org/D4661
llvm-svn: 237608
This reverts commit 742dc9b6c9686ab52860b7da39c3a126d8a97fbc.
This is generating multiple segfaults in our internal builds.
Test case coming up shortly.
llvm-svn: 237391
Emit warning when operand to `delete` is allocated with `new[]` or
operand to `delete[]` is allocated with `new`.
Reviewers: rtrieu, jordan_rose, rsmith
Subscribers: majnemer, cfe-commits
Differential Revision: http://reviews.llvm.org/D4661
llvm-svn: 237368
TODO: support realloc(). Currently it is not possible due to the present realloc() handling. Currently RegionState is not being attached to realloc() in case of a zero Size argument.
llvm-svn: 234889
Again, this is being applied in a separate commit so that the previous commit
can be reverted while leaving the test in place.
rdar://problem/20335433
llvm-svn: 233593
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
llvm-svn: 233592
Give up this checking in order to continue tracking that these values came from
direct ivar access, which will be important in the next commit.
Part of rdar://problem/20335433
llvm-svn: 233591
Fixes https://llvm.org/bugs/show_bug.cgi?id=20744
struct A {
A() = default;
};
Previously the source range of the declaration of A ended at the ')'. It should
include the '= default' part as well. The same for '= delete'.
Note: this will break one of the clang-tidy fixers, which is going to be
addessed in a follow-up patch.
Differential Revision: http://reviews.llvm.org/D8465
llvm-svn: 233028
Similarly, don't assume +0 if the property's setter is manually implemented.
In both cases, if the property's ownership is explicitly written, then we /do/
assume the ivar has the same ownership.
rdar://problem/20218183
llvm-svn: 232849
CloudABI also supports the arc4random() function. We can enable compiler
warnings for rand(), random() and *rand48() on this system as well.
llvm-svn: 231914
In theory we could assume a CF property is stored at +0 if there's not a custom
setter, but that's not really worth the complexity. What we do know is that a
CF property can't have ownership attributes, and so we shouldn't assume anything
about the ownership of the ivar.
rdar://problem/20076963
llvm-svn: 231553
Modules and Tooling tests in particular tend to want to change the cwd,
so we were missing test coverage in this area on Windows. It should now
be easier to write such portable tests.
llvm-svn: 231029
We expect in general that any nil value has no retain count information
associated with it; violating this results in unexpected state unification
/later/ when we decide to throw the information away. Unexpectedly caching
out can lead to an assertion failure or crash.
rdar://problem/19862648
llvm-svn: 229934
+ separate bug report for "Free alloca()" error to be able to customize checkers responsible for this error.
+ Muted "Free alloca()" error for NewDelete checker that is not responsible for c-allocated memory, turned on for unix.MismatchedDeallocator checker.
+ RefState for alloca() - to be able to detect usage of zero-allocated memory by upcoming ZeroAllocDereference checker.
+ AF_Alloca family to handle alloca() consistently - keep proper family in RefState, handle 'alloca' by getCheckIfTracked() facility, etc.
+ extra tests.
llvm-svn: 229850
PrettyStackTrace now requires the ENABLE_BACKTRACES option. We need to check for that here or these tests fail llvm-lit.
Reviewed by chandlerc
llvm-svn: 228735
to the plist output. This check_name field does not guaranteed to be the
same as the name of the checker in the future.
Reviewer: Anna Zaks
Differential Revision: http://reviews.llvm.org/D6841
llvm-svn: 228624
The analyzer thinks that ArraySubscriptExpr cannot be an r-value (ever).
However, it can be in some corner cases. Specifically, C forbids expressions
of unqualified void type from being l-values.
Note, the analyzer will keep modeling the subscript expr as an l-value. The
analyzer should be treating void* as a char array
(https://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Pointer-Arith.html).
llvm-svn: 228249
Instead of handling edge cases (mostly involving blocks), where we have difficulty finding
an allocation statement, allow the allocation site to be in a parent node.
Previously we assumed that the allocation site can always be found in the same frame
as allocation, but there are scenarios in which an element is leaked in a child
frame but is allocated in the parent.
llvm-svn: 228247
A refinement of r204730, itself a refinement of r198953, to better handle
cases where an object is accessed both through a property getter and
through direct ivar access. An object accessed through a property should
always be treated as +0, i.e. not owned by the caller. However, an object
accessed through an ivar may be at +0 or at +1, depending on whether the
ivar is a strong reference. Outside of ARC, we don't always have that
information.
The previous attempt would clear out the +0 provided by a getter, but only
if that +0 hadn't already participated in other retain counting operations.
(That is, "self.foo" is okay, but "[[self.foo retain] autorelease]" is
problematic.) This turned out to not be good enough when our synthesized
getters get involved.
This commit drops the notion of "overridable" reference counting and instead
just tracks whether a value ever came from a (strong) ivar. If it has, we
allow one more release than we otherwise would. This has the added benefit
of being able to catch /some/ overreleases of instance variables, though
it's not likely to come up in practice.
We do still get some false negatives because we currently throw away
refcount state upon assigning a value into an ivar. We should probably
improve on that in the future, especially once we synthesize setters as
well as getters.
rdar://problem/18075108
llvm-svn: 228174
A patch by Daniel DeFreez!
We were previously dropping edges on re-declarations. Store the
canonical declarations in the graph to ensure that different
references to the same function end up reflected with the same call graph
node.
(Note, this might lead to performance fluctuation because call graph
is used to determine the function analysis order.)
llvm-svn: 224398
This suppresses a common false positive when analyzing libc++.
Along the way, introduce some tests to show this checker actually
works with C++ static_cast<>.
llvm-svn: 220160
The return value of mempcpy is only correct when the destination type is
one byte in size. This patch casts the argument to a char* so the
calculation is also correct for structs, ints etc.
A patch by Daniel Fahlgren!
llvm-svn: 219024
in the super class, do not issue the warning about property
in current class's protocol will not be auto synthesized.
// rdar://18179833
llvm-svn: 216769
People have been incorrectly using "-analyzer-disable-checker" to
silence analyzer warnings on a file, when analyzing a project. Add
the "-analyzer-disable-all-checks" option, which would allow the
suppression and suggest it as part of the error message for
"-analyzer-disable-checker". The idea here is to compose this with
"--analyze" so that users can selectively opt out specific files from
static analysis.
llvm-svn: 216763
Do not warn when property declared in class's protocol will be auto-synthesized
by its uper class implementation because super class has also declared this
property while this class has not. Continue to warn if current class
has declared the property also (because this declaration will not result
in a 2nd synthesis).
rdar://18152478
llvm-svn: 216753
Currently the analyzer lazily models some functions using 'BodyFarm',
which constructs a fake function implementation that the analyzer
can simulate that approximates the semantics of the function when
it is called. BodyFarm does this by constructing the AST for
such definitions on-the-fly. One strength of BodyFarm
is that all symbols and types referenced by synthesized function
bodies are contextual adapted to the containing translation unit.
The downside is that these ASTs are hardcoded in Clang's own
source code.
A more scalable model is to allow these models to be defined as source
code in separate "model" files and have the analyzer use those
definitions lazily when a function body is needed. Among other things,
it will allow more customization of the analyzer for specific APIs
and platforms.
This patch provides the initial infrastructure for this feature.
It extends BodyFarm to use an abstract API 'CodeInjector' that can be
used to synthesize function bodies. That 'CodeInjector' is
implemented using a new 'ModelInjector' in libFrontend, which lazily
parses a model file and injects the ASTs into the current translation
unit.
Models are currently found by specifying a 'model-path' as an
analyzer option; if no path is specified the CodeInjector is not
used, thus defaulting to the current behavior in the analyzer.
Models currently contain a single function definition, and can
be found by finding the file <function name>.model. This is an
initial starting point for something more rich, but it bootstraps
this feature for future evolution.
This patch was contributed by Gábor Horváth as part of his
Google Summer of Code project.
Some notes:
- This introduces the notion of a "model file" into
FrontendAction and the Preprocessor. This nomenclature
is specific to the static analyzer, but possibly could be
generalized. Essentially these are sources pulled in
exogenously from the principal translation.
Preprocessor gets a 'InitializeForModelFile' and
'FinalizeForModelFile' which could possibly be hoisted out
of Preprocessor if Preprocessor exposed a new API to
change the PragmaHandlers and some other internal pieces. This
can be revisited.
FrontendAction gets a 'isModelParsingAction()' predicate function
used to allow a new FrontendAction to recycle the Preprocessor
and ASTContext. This name could probably be made something
more general (i.e., not tied to 'model files') at the expense
of losing the intent of why it exists. This can be revisited.
- This is a moderate sized patch; it has gone through some amount of
offline code review. Most of the changes to the non-analyzer
parts are fairly small, and would make little sense without
the analyzer changes.
- Most of the analyzer changes are plumbing, with the interesting
behavior being introduced by ModelInjector.cpp and
ModelConsumer.cpp.
- The new functionality introduced by this change is off-by-default.
It requires an analyzer config option to enable.
llvm-svn: 216550
Also, make it slightly clearer what's being tested by only differentiating integer
literals based on their suffix, rather than using a very large constant.
llvm-svn: 216133
Yet more problems due to the missing CXXBindTemporaryExpr in the CFG for
default arguments.
Unfortunately we cannot just switch off inserting temporaries for the
corresponding default arguments, as that breaks existing tests
(test/SemaCXX/return-noreturn.cpp:245).
llvm-svn: 215554
In cases like:
struct C { ~C(); }
void f(C c = C());
void t() {
f();
}
We currently do not add the CXXBindTemporaryExpr for the temporary (the
code mentions that as the default parameter expressions are owned by
the declaration, we'd otherwise add the same expression multiple times),
but we add the temporary destructor pointing to the CXXBindTemporaryExpr.
We need to fix that before we can re-enable the assertion.
llvm-svn: 215357
Changes to the original patch:
- model the CFG for temporary destructors in conditional operators so that
the destructors of the true and false branch are always exclusive. This
is necessary because we must not have impossible paths for the path
based analysis to work.
- add multiple regression tests with ternary operators
Original description:
Fix modelling of non-lifetime-extended temporary destructors in the
analyzer.
Changes to the CFG:
When creating the CFG for temporary destructors, we create a structure
that mirrors the branch structure of the conditionally executed
temporary constructors in a full expression.
The branches we create use a CXXBindTemporaryExpr as terminator which
corresponds to the temporary constructor which must have been executed
to enter the destruction branch.
2. Changes to the Analyzer:
When we visit a CXXBindTemporaryExpr we mark the CXXBindTemporaryExpr as
executed in the state; when we reach a branch that contains the
corresponding CXXBindTemporaryExpr as terminator, we branch out
depending on whether the corresponding CXXBindTemporaryExpr was marked
as executed.
llvm-svn: 215096
This reverts commit r214962 because after the change the
following code doesn't compile with -Wreturn-type -Werror.
#include <cstdlib>
class NoReturn {
public:
~NoReturn() __attribute__((noreturn)) { exit(1); }
};
int check() {
true ? NoReturn() : NoReturn();
}
llvm-svn: 214998
1. Changes to the CFG:
When creating the CFG for temporary destructors, we create a structure
that mirrors the branch structure of the conditionally executed
temporary constructors in a full expression.
The branches we create use a CXXBindTemporaryExpr as terminator which
corresponds to the temporary constructor which must have been executed
to enter the destruction branch.
2. Changes to the Analyzer:
When we visit a CXXBindTemporaryExpr we mark the CXXBindTemporaryExpr as
executed in the state; when we reach a branch that contains the
corresponding CXXBindTemporaryExpr as terminator, we branch out
depending on whether the corresponding CXXBindTemporaryExpr was marked
as executed.
llvm-svn: 214962
MaterializeTemporaryExpr already contains information about the lifetime
of the temporary; if the lifetime is not the full statement, we do not
want to emit a destructor at the end of the full statement for it.
llvm-svn: 214292
This new checker, alpha.core.TestAfterDivZero, catches issues like this:
int sum = ...
int avg = sum / count; // potential division by zero...
if (count == 0) { ... } // ...caught here
Because the analyzer does not necessarily explore /all/ paths through a program,
this check is restricted to only work on zero checks that immediately follow a
division operation (/ % /= %=). This could later be expanded to handle checks
dominated by a division operation but not necessarily in the same CFG block.
Patch by Anders Rönnholm! (with very minor modifications by me)
llvm-svn: 212731
This silences false positives (leaks, use of uninitialized value) in simple
code that uses containers such as std::vector and std::list. The analyzer
cannot reason about the internal invariances of those data structures which
leads to false positives. Until we come up with a better solution to that
problem, let's just not inline the methods of the containers and allow objects
to escape whenever such methods are called.
This just extends an already existing flag "c++-container-inlining" and applies
the heuristic not only to constructors and destructors of the containers, but
to all of their methods.
We have a bunch of distinct user reports all related to this issue
(radar://16058651, radar://16580751, radar://16384286, radar://16795491
[PR19637]).
llvm-svn: 211832
When adding the implicit compound statement (required for Codegen?), the
end location was previously overridden by the start location, probably
based on the assumptions:
* The location of the compound statement should be the member's location
* The compound statement if present is the last element of a FunctionDecl
This patch changes the location of the compound statement to the
member's end location.
Code review: http://reviews.llvm.org/D4175
llvm-svn: 211344
Doing this caused us to mistakenly think we'd seen a particular state before
when we actually hadn't, which resulted in false negatives. Credit to
Rafael Auler for discovering this issue!
llvm-svn: 211209
Fixes a crash in Retain Count checker error reporting logic by handing
the allocation statement retrieval from a BlockEdge program point.
Also added a simple CFG dump routine for debugging.
llvm-svn: 210960
This applies to __attribute__((pure)) as well, but 'const' is more interesting
because many of our builtins are marked 'const'.
PR19661
llvm-svn: 208154
The assignment needs to be before the destruction of the temporary.
This patch calls out to addStmt, which invokes VisitDeclStmt, which has
all the correct logic for handling temporaries.
llvm-svn: 207985
Document and simplify ResolveCondition.
1. Introduce a temporary special case for temporary desctructors when resolving
the branch condition - in an upcoming patch, alexmc will change temporary
destructor conditions to not run through this logic, in which case we can remove
this (marked as FIXME); this currently fixes a crash.
2. Simplify ResolveCondition; while documenting the function, I noticed that it
always returns the last statement - either that statement is the condition
itself (in which case the condition was returned anyway), or the rightmost
leaf is returned; for correctness, the rightmost leaf must be evaluated anyway
(which the CFG does in the last statement), thus we can just return the last
statement in that case, too. Added an assert to verify the invariant.
llvm-svn: 207957
The constructor that comes right before a variable declaration in the CFG might
not be the initialization of that variable. Previously, we just checked that
the variable's initializer expression was different from the construction
expression, but forgot to see whether the variable had an initializer expression
at all.
Thanks for the prompting, David.
llvm-svn: 207562
While we don't model pointer-to-member operators yet (neither .* nor ->*),
CallAndMessageChecker still checks to make sure the 'this' object is not
null or undefined first. However, it also expects that the object should
always have a valid MemRegion, something that's generally important elsewhere
in the analyzer as well. Ensure this is true ahead of time, just like we do
for member access.
PR19531
llvm-svn: 207561
This also includes some infrastructure to make it easier to build multi-argument
selectors, rather than trying to use string matching on each piece. There's a bit
more setup code, but less cost at runtime.
PR18908
llvm-svn: 205827
Fixes a false positive when temporary destructors are enabled where a temporary
is destroyed after a variable is constructed but before the VarDecl itself is
processed, which occurs when the variable is in the condition of an if or while.
Patch by Alex McCarthy, with an extra test from me.
llvm-svn: 205661
For namespaces, this is consistent with mangling and GCC's debug info
behavior. For structs, GCC uses <anonymous struct> but we prefer
consistency between all anonymous entities but don't want to confuse
them with template arguments, etc, so we'll just go with parens in all
cases.
llvm-svn: 205398
If we're trying to get the zero element region of something that's not a region,
we should be returning UnknownVal, which is what ProgramState::getLValue will
do for us.
Patch by Alex McCarthy!
llvm-svn: 205327
Add M_ZERO awareness to malloc() static analysis in Clang for FreeBSD,
NetBSD, and OpenBSD in a similar fashion to O_CREAT for open(2).
These systems have a three-argument malloc() in the kernel where the
third argument contains flags; the M_ZERO flag will zero-initialize the
allocated buffer.
This should reduce the number of false positives when running static
analysis on BSD kernels.
Additionally, add kmalloc() (Linux kernel malloc()) and treat __GFP_ZERO
like M_ZERO on Linux.
Future work involves a better method of checking for named flags without
hardcoding values.
Patch by Conrad Meyer, with minor modifications by me.
llvm-svn: 204832
A refinement of r198953 to handle cases where an object is accessed both through
a property getter and through direct ivar access. An object accessed through a
property should always be treated as +0, i.e. not owned by the caller. However,
an object accessed through an ivar may be at +0 or at +1, depending on whether
the ivar is a strong reference. Outside of ARC, we don't have that information,
so we just don't track objects accessed through ivars.
With this change, accessing an ivar directly will deliberately override the +0
provided by a getter, but only if the +0 hasn't participated in other retain
counting yet. That isn't perfect, but it's already unusual for people to be
mixing property access with direct ivar access. (The primary use case for this
is in setters, init methods, and -dealloc.)
Thanks to Ted for spotting a few mistakes in private review.
<rdar://problem/16333368>
llvm-svn: 204730
Passing a pointer to an uninitialized memory buffer is normally okay,
but if the function is declared to take a pointer-to-const then it's
very unlikely it will be modifying the buffer. In this case the analyzer
should warn that there will likely be a read of uninitialized memory.
This doesn't check all elements of an array, only the first one.
It also doesn't yet check Objective-C methods, only C functions and
C++ methods.
This is controlled by a new check: alpha.core.CallAndMessageUnInitRefArg.
Patch by Per Viberg!
llvm-svn: 203822
Like the binary operator check of r201702, this actually checks the
condition of every if in a chain against every other condition, an
O(N^2) operation. In most cases N should be small enough to make this
practical, and checking all cases like this makes it much more likely
to catch a copy-paste error within the same series of branches.
Part of IdenticalExprChecker; patch by Daniel Fahlgren!
llvm-svn: 203585
null comparison when the pointer is known to be non-null.
This catches the array to pointer decay, function to pointer decay and
address of variables. This does not catch address of function since this
has been previously used to silence a warning.
Pointer to bool conversion is under -Wbool-conversion.
Pointer to null comparison is under -Wtautological-pointer-compare, a sub-group
of -Wtautological-compare.
void foo() {
int arr[5];
int x;
// warn on these conditionals
if (foo);
if (arr);
if (&x);
if (foo == null);
if (arr == null);
if (&x == null);
if (&foo); // no warning
}
llvm-svn: 202216
For now, just ignore them. Later, we could try looking through LazyCompoundVals,
but we at least shouldn't crash.
<rdar://problem/16153464>
llvm-svn: 202212
Somehow both Daniel and I missed the fact that while loops are only identical
if they have identical bodies.
Patch by Daniel Fahlgren!
llvm-svn: 201829
IdenticalExprChecker now warns if any expressions in a logical or bitwise
chain (&&, ||, &, |, or ^) are the same. Unlike the previous patch, this
actually checks all subexpressions against each other (an O(N^2) operation,
but N is likely to be small).
Patch by Daniel Fahlgren!
llvm-svn: 201702
This extends the checks for identical expressions to handle identical
statements, and compares the consequent and alternative ("then" and "else")
branches of an if-statement to see if they are identical, treating a single
statement surrounded by braces as equivalent to one without braces.
This does /not/ check subsequent branches in an if/else chain, let alone
branches that are not consecutive. This may improve in a future patch, but
it would certainly take more work.
Patch by Daniel Fahlgren!
llvm-svn: 201701
Devin Coughlin