Changes the analyzer to believe that methods annotated with _Nonnull
from system frameworks indeed return non null objects.
Local methods with such annotation are still distrusted.
rdar://24291919
Differential Revision: https://reviews.llvm.org/D44341
llvm-svn: 328282
When a temporary is constructed with a proper construction context, it should
be safe to inline the destructor. We have added suppressions for some of the
common false positives caused by such inlining, so there should be - and from my
observations there indeed is - more benefit than harm from enabling destructor
inlining.
Differential Revision: https://reviews.llvm.org/D44721
llvm-svn: 328258
CXXCtorInitializer-based constructors are also affected by the C++17 mandatory
copy elision, like variable constructors and return value constructors.
Extend r328248 to support those.
Differential Revision: https://reviews.llvm.org/D44763
llvm-svn: 328255
Function return values can be constructed directly in variables or passed
directly into return statements, without even an elidable copy in between.
This is how the C++17 mandatory copy elision AST behaves. The behavior we'll
have in such cases is the "old" behavior that we've had before we've
implemented destructor inlining and proper lifetime extension support.
Differential Revision: https://reviews.llvm.org/D44755
llvm-svn: 328253
In C++17 copy elision is mandatory for variable and return value constructors
(as long as it doesn't involve type conversion) which results in AST that does
not contain elidable constructors in their usual places. In order to provide
construction contexts in this scenario we need to cover more AST patterns.
This patch makes the CFG prepared for these scenarios by:
- Fork VariableConstructionContext and ReturnedValueConstructionContext into
two different sub-classes (each) one of which indicates the C++17 case and
contains a reference to an extra CXXBindTemporaryExpr.
- Allow CFGCXXRecordTypedCall element to accept VariableConstructionContext and
ReturnedValueConstructionContext as its context.
Differential Revision: https://reviews.llvm.org/D44597
llvm-svn: 328248
If a memory region (or an SVal that represents a pointer to that memory region)
is a (direct or indirect, not necessarily proper) sub-region of a SymbolicRegion
then it is said to have a symbolic base.
For now SVal::symbol_iterator explores the symbol within a symbolic region
only when the SVal represents a pointer to the symbolic region itself,
not to any of its sub-regions.
This behavior is not indended by any user of symbol_iterator; all users who
cared about such behavior were expecting the iterator to descend into the
symbolic base of an arbitrary region, find the parent symbol of the symbolic
base region, and iterate over that symbol. Lack of such behavior resulted in
bugs demonstarted by the test cases.
Hence the decision to change the API to behave more intuitively.
Differential Revision: https://reviews.llvm.org/D44347
llvm-svn: 328247
r326249 wasn't quite enough because we often run out of inlining stack depth
limit and for that reason fail to see the atomics we're looking for.
Add a more straightforward false positive suppression that is based on the name
of the class. I.e. if we're releasing a pointer in a destructor of a "something
shared/intrusive/reference/counting something ptr/pointer something", then any
use-after-free or double-free that occurs later would likely be a false
positive.
rdar://problem/38013606
Differential Revision: https://reviews.llvm.org/D44281
llvm-svn: 328066
When the loop has a null terminator statement and sets 'widen-loops=true', 'invalidateRegions' will constructs the 'SymbolConjured' with null 'Stmt'. And this will lead to a crash in 'IteratorChecker.cpp'. This patch use 'dyn_cast_or_null<>' instead of 'dyn_cast<>' in IteratorChecker.cpp.
Differential Revision: https://reviews.llvm.org/D44606
llvm-svn: 327962
Also use the opportunity to clean up the code and remove unnecessary duplication.
rdar://37625895
Differential Revision: https://reviews.llvm.org/D44594
llvm-svn: 327926
For other regions, the error message contains a good indication of the
problem, and there, in general, nothing helpful we can print.
Error pointer to the problematic expression seems enough.
rdar://37323555
Differential Revision: https://reviews.llvm.org/D44409
llvm-svn: 327727
Call expressions that return objects by an lvalue reference or an rvalue
reference have a value type in the AST but wear an auxiliary flag of being an
lvalue or an xvalue respectively.
Use the helper method for obtaining the actual return type of the function.
Fixes a crash.
Differential Revision: https://reviews.llvm.org/D44273
llvm-svn: 327352
Properly perform destruction and lifetime extension of such temporaries.
C++ object-type return values of conservatively evaluated functions are now
represented as compound values of well-defined temporary object regions. The
function creates a region that represents the temporary object and will later
be used for destruction or materialization, invalidates it, and returns the
invalidated compound value of the object.
Differential Revision: https://reviews.llvm.org/D44131
llvm-svn: 327348
This patch uses the newly added CFGCXXRecordTypedCall element at the call site
of the caller to construct the return value within the callee directly into the
caller's stack frame. This way it is also capable of populating the temporary
destructor and lifetime extension maps for the temporary, which allows
temporary destructors and lifetime extension to work correctly.
This patch does not affect temporaries that were returned from conservatively
evaluated functions.
Differential Revision: https://reviews.llvm.org/D44124
llvm-svn: 327345
This patch adds a new CFGStmt sub-class, CFGCXXRecordTypedCall, which replaces
the regular CFGStmt for the respective CallExpr whenever the CFG has additional
information to provide regarding the lifetime of the returned value.
This additional call site information is represented by a ConstructionContext
(which was previously used for CFGConstructor elements) that provides references
to CXXBindTemporaryExpr and MaterializeTemporaryExpr that surround the call.
This corresponds to the common C++ calling convention solution of providing
the target address for constructing the return value as an auxiliary implicit
argument during function call.
One of the use cases for such extra context at the call site would be to perform
any sort of inter-procedural analysis over the CFG that involves functions
returning objects by value. In this case the elidable constructor at the return
site would construct the object explained by the context at the call site, and
its lifetime would also be managed by the caller, not the callee.
The extra context would also be useful for properly handling the return-value
temporary at the call site, even if the callee is not being analyzed
inter-procedurally.
Differential Revision: https://reviews.llvm.org/D44120
llvm-svn: 327343
This patch adds two new CFG elements CFGScopeBegin and CFGScopeEnd that indicate
when a local scope begins and ends respectively. We use first VarDecl declared
in a scope to uniquely identify it and add CFGScopeBegin and CFGScopeEnd elements
into corresponding basic blocks.
Differential Revision: https://reviews.llvm.org/D16403
llvm-svn: 327258
mprotect() allows setting memory access flags similarly to mmap(),
causing similar security issues if these flags are needlessly broad.
Patch by David Carlier!
Differential Revision: https://reviews.llvm.org/D44250
llvm-svn: 327098
Implicit constructor conversions such as A a = B() are represented by
surrounding the constructor for B() with an ImplicitCastExpr of
CK_ConstructorConversion kind, similarly to how explicit constructor conversions
are surrounded by a CXXFunctionalCastExpr. Support this syntax pattern when
extracting the construction context for the implicit constructor that
performs the conversion.
Differential Revision: https://reviews.llvm.org/D44051
llvm-svn: 327096
Previously, iteration through nil objects which resulted from
objc-messages being set to nil were modeled incorrectly.
There are a couple of notes about this patch:
In principle, ExprEngineObjC might be left untouched IFF osx.loops
checker is enabled.
I however think that we should not do something
completely incorrect depending on what checkers are left on.
We should evaluate and potentially remove altogether the isConsumedExpr
performance heuristic, as it seems very fragile.
rdar://22205149
Differential Revision: https://reviews.llvm.org/D44178
llvm-svn: 326982
Proper modeling still remains to be done.
Note that BindingDecl#getHoldingVar() is almost always null, and this
should probably be handled by dealing with DecompositionDecl beforehand.
rdar://36852163
Differential Revision: https://reviews.llvm.org/D44183
llvm-svn: 326951
Summary:
There is a problem with analyzer that a wrong value is given when modeling the increment operator of the operand with type bool. After `rL307604` is applied, a unsigned overflow may occur.
Example:
```
void func() {
bool b = true;
// unsigned overflow occur, 2 -> 0 U1b
b++;
}
```
The use of an operand of type bool with the ++ operators is deprecated but valid untill C++17. And if the operand of the increment operator is of type bool, it is set to true.
This patch includes two parts:
- If the operand of the increment operator is of type bool or type _Bool, set to true.
- Modify `BasicValueFactory::getTruthValue()`, use `getIntWidth()` instead `getTypeSize()` and use `unsigned` instead `signed`.
Reviewers: alexshap, NoQ, dcoughlin, george.karpenkov
Reviewed By: NoQ
Subscribers: xazax.hun, szepet, a.sidorin, cfe-commits, MTC
Differential Revision: https://reviews.llvm.org/D43741
llvm-svn: 326776
Summary:
GenericTaintChecker can't recognize stdin in some cases. The reason is that `if (PtrTy->getPointeeType() == C.getASTContext().getFILEType()` does not hold when stdin is encountered.
My platform is ubuntu16.04 64bit, gcc 5.4.0, glibc 2.23. The definition of stdin is as follows:
```
__BEGIN_NAMESPACE_STD
/* The opaque type of streams. This is the definition used elsewhere. */
typedef struct _IO_FILE FILE;
___END_NAMESPACE_STD
...
/* The opaque type of streams. This is the definition used elsewhere. */
typedef struct _IO_FILE __FILE;
...
/* Standard streams. */
extern struct _IO_FILE *stdin; /* Standard input stream. */
extern struct _IO_FILE *stdout; /* Standard output stream. */
extern struct _IO_FILE *stderr; /* Standard error output stream. */
```
The type of stdin is as follows AST:
```
ElaboratedType 0xc911170'struct _IO_FILE'sugar
`-RecordType 0xc911150'struct _IO_FILE'
`-CXXRecord 0xc923ff0'_IO_FILE'
```
`C.getASTContext().GetFILEType()` is as follows AST:
```
TypedefType 0xc932710 'FILE' sugar
|-Typedef 0xc9111c0 'FILE'
`-ElaboratedType 0xc911170 'struct _IO_FILE' sugar
`-RecordType 0xc911150 'struct _IO_FILE'
`-CXXRecord 0xc923ff0 '_IO_FILE'
```
So I think it's better to use `getCanonicalType()`.
Reviewers: zaks.anna, NoQ, george.karpenkov, a.sidorin
Reviewed By: zaks.anna, a.sidorin
Subscribers: a.sidorin, cfe-commits, xazax.hun, szepet, MTC
Differential Revision: https://reviews.llvm.org/D39159
llvm-svn: 326709
```
if (NSNumber* x = ...)
```
is a reasonable pattern in objc++, we should not warn on it.
rdar://35152234
Differential Revision: https://reviews.llvm.org/D44044
llvm-svn: 326619
Don't enable c++-temp-dtor-inlining by default yet, due to this reference
counting pointe problem.
Otherwise the new mode seems stable and allows us to incrementally fix C++
problems in much less hacky ways.
Differential Revision: https://reviews.llvm.org/D43804
llvm-svn: 326461
Originally submitted as r326323 and r326324.
Reverted in r326432.
Reverting the commit was a mistake.
The breakage was due to invalid build files in our internal buildsystem,
CMakeLists did not have any cyclic dependencies.
llvm-svn: 326439
Also revert "[analyzer] Fix a compiler warning"
This reverts commits r326323 and r326324.
Reason: the commits introduced a cyclic dependency in the build graph.
This happens to work with cmake, but breaks out internal integrate.
llvm-svn: 326432
This is a security check that warns when both PROT_WRITE and PROT_EXEC are
set during mmap(). If mmap()ed memory is both writable and executable, it makes
it easier for the attacker to execute arbitrary code when contents of this
memory are compromised. Some applications require such mmap()s though, such as
different sorts of JIT.
Re-applied after a revert in r324167.
Temporarily stays in the alpha package because it needs a better way of
determining macro values that are not immediately available in the AST.
Patch by David Carlier!
Differential Revision: https://reviews.llvm.org/D42645
llvm-svn: 326405
For now. We should also add support for ConstructorConversion casts as presented
in the attached test case, but this requires more changes because AST around
them seems different.
The check was originally present but was accidentally lost during r326021.
Differential Revision: https://reviews.llvm.org/D43840
llvm-svn: 326402
The aim of this patch is to be minimal to enable incremental development of
the feature on the top of the tree. This patch should be an NFC when the
feature is turned off. It is turned off by default and still considered as
experimental.
Technical details are available in the EuroLLVM Talk:
http://llvm.org/devmtg/2017-03//2017/02/20/accepted-sessions.html#7
Note that the initial prototype was done by A. Sidorin et al.: http://lists.llvm.org/pipermail/cfe-dev/2015-October/045730.html
Contributions to the measurements and the new version of the code: Peter Szecsi, Zoltan Gera, Daniel Krupp, Kareem Khazem.
Differential Revision: https://reviews.llvm.org/D30691
llvm-svn: 326323
When a class forgets to initialize a field in the constructor, and then gets
copied around, a warning is emitted that the value assigned to a specific field
is undefined.
When the copy/move constructor is implicit (not written out in the code) but not
trivial (is not a trivial memory copy, eg. because members have an explicit copy
constructor), the body of such constructor is auto-generated in the AST.
In this case the checker's warning message is squeezed at the top of
the class declaration, and it gets hard to guess which field is at fault.
Fix the warning message to include the name of the field.
Differential Revision: https://reviews.llvm.org/D43798
llvm-svn: 326258
Throw away MallocChecker warnings that occur after releasing a pointer within a
destructor (or its callees) after performing C11 atomic fetch_add or fetch_sub
within that destructor (or its callees).
This is an indication that the destructor's class is likely a
reference-counting pointer. The analyzer is not able to understand that the
original reference count is usually large enough to avoid most use-after-frees.
Even when the smart pointer is a local variable, we still have these false
positives that this patch suppresses, because the analyzer doesn't currently
support atomics well enough.
Differential Revision: https://reviews.llvm.org/D43791
llvm-svn: 326249
The SVal for any empty C++ object is an UnknownVal. Because RegionStore does
not have binding extents, binding an empty object to an UnknownVal may
potentially overwrite existing bindings at the same offset.
Therefore, when performing a trivial copy of an empty object, don't try to
take the value of the object and bind it to the copy. Doing nothing is accurate
enough, and it doesn't screw any existing bindings.
Differential Revision: https://reviews.llvm.org/D43714
llvm-svn: 326247
Sometimes it is not known at compile time which temporary objects will be
constructed, eg. 'x ? A() : B()' or 'C() || D()'. In this case we track which
temporary was constructed to know how to properly call the destructor.
Once the construction context for temporaries was introduced, we moved the
tracking code to the code that investigates the construction context.
Bring back the old mechanism because construction contexts are not always
available yet - eg. in the case where a temporary is constructed without a
constructor expression, eg. returned from a function by value. The mechanism
should still go away eventually.
Additionally, fix a bug in the temporary cleanup code for the case when
construction contexts are not available, which could lead to temporaries
staying in the program state and increasing memory consumption.
Differential Revision: https://reviews.llvm.org/D43666
llvm-svn: 326246
If a variable or an otherwise a concrete typed-value region is being
placement-new'ed into, its dynamic type may change in arbitrary manners. And
when the region is used, there may be a third type that's different from both
the static and the dynamic type. It cannot be *completely* different from the
dynamic type, but it may be a base class of the dynamic type - and in this case
there isn't (and shouldn't be) any indication anywhere in the AST that there is
a derived-to-base cast from the dynamic type to the third type.
Perform a generic cast (evalCast()) from the third type to the dynamic type
in this case. From the point of view of the SVal hierarchy, this would have
produced non-canonical SVals if we used such generic cast in the normal case,
but in this case there doesn't seem to be a better option.
Differential Revision: https://reviews.llvm.org/D43659
llvm-svn: 326245
Automatic destructors are missing in the CFG in situations like
const int &x = C().x;
For now it's better to disable construction inlining, because inlining
constructors while doing nothing on destructors is very bad.
Differential Revision: https://reviews.llvm.org/D43689
llvm-svn: 326240
This patch uses the reference to MaterializeTemporaryExpr stored in the
construction context since r326014 in order to model that expression correctly.
When modeling MaterializeTemporaryExpr, instead of copying the raw memory
contents from the sub-expression's rvalue to a completely new temporary region,
that we conjure up for the lack of better options, we now have the better
option to recall the region into which the object was originally constructed
and declare that region to be the value of the expression, which is semantically
correct.
This only works when the construction context is available, which is worked on
independently.
The temporary region's liveness (in the sense of removeDeadBindings) is extended
until the MaterializeTemporaryExpr is resolved, in order to keep the store
bindings around, because it wouldn't be referenced from anywhere else in the
program state.
Differential Revision: https://reviews.llvm.org/D43497
llvm-svn: 326236
Fixes https://bugs.llvm.org/show_bug.cgi?id=36474
In general, getSVal API should be changed so that it does not crash on
some non-obvious conditions.
It should either be updated to require a type, or to return Optional<SVal>.
Differential Revision: https://reviews.llvm.org/D43801
llvm-svn: 326233
See D42775 for discussion. Turns out, just exploring nodes which
weren't explored first is not quite enough, as e.g. the first quick
traversal resulting in a report can mark everything as "visited", and
then subsequent traversals of the same region will get all the pitfalls
of DFS.
Priority queue-based approach in comparison shows much greater
increase in coverage and even performance, without sacrificing memory.
Differential Revision: https://reviews.llvm.org/D43354
llvm-svn: 326136
Bison/YACC generated files result in a very large number of (presumably)
false positives from the analyzer.
These false positives are "true" in a sense of the information analyzer
sees: assuming that the lexer can return any token at any point a number
of uninitialized reads does occur.
(naturally, the analyzer can not capture a complex invariant that
certain tokens can only occur under certain conditions).
Current fix simply stops analysis on those files.
I have examined a very large number of such auto-generated files, and
they do all start with such a comment.
Conversely, user code is very unlikely to contain such a comment.
rdar://33608161
Differential Revision: https://reviews.llvm.org/D43421
llvm-svn: 326135
Addresses https://bugs.llvm.org/show_bug.cgi?id=36206
rdar://37159026
A proper fix would be much harder, and would involve changing the
appropriate code in ExprEngine to be aware of the size limitations of
the type used for addressing.
Differential Revision: https://reviews.llvm.org/D43218
llvm-svn: 326122
When a lifetime-extended temporary is on a branch of a conditional operator,
materialization of such temporary occurs after the condition is resolved.
This change allows us to understand, by including the MaterializeTemporaryExpr
in the construction context, the target for temporary materialization in such
cases.
Differential Revision: https://reviews.llvm.org/D43483
llvm-svn: 326019
In order to bind a temporary to a const lvalue reference, a no-op cast is added
to make the temporary itself const, and only then the reference is taken
(materialized). Skip the no-op cast when looking for the construction context.
Differential Revision: https://reviews.llvm.org/D43481
llvm-svn: 326016
When a constructor of a temporary with a single argument is treated
as a functional cast expression, skip the functional cast expression
and provide the correct construction context for the temporary.
Differential Revision: https://reviews.llvm.org/D43480
llvm-svn: 326015
When constructing a temporary that is going to be lifetime-extended through a
MaterializeTemporaryExpr later, CFG elements for the respective constructor
can now be queried to obtain the reference to that MaterializeTemporaryExpr
and therefore gain information about lifetime extension.
This may produce multi-layered construction contexts when information about
both temporary destruction and lifetime extension is available.
Differential Revision: https://reviews.llvm.org/D43477
llvm-svn: 326014
The assertion gets exposed when changing the exploration order.
This is a quick hacky fix, but the intention is that if the nodes do
merge, it should not matter which predecessor should be traverse.
A proper fix would be not to traverse predecessors at all, as all
information relevant for any decision should be avilable locally.
rdar://37540480
Differential Revision: https://reviews.llvm.org/D42773
llvm-svn: 325977
In the wild, many cases of null pointer dereference, or uninitialized
value read occur because the value was meant to be initialized by the
inlined function, but did not, most often due to error condition in the
inlined function.
This change highlights the return branch taken by the inlined function,
in order to help user understand the error report and see why the value
was uninitialized.
rdar://36287652
Differential Revision: https://reviews.llvm.org/D41848
llvm-svn: 325976
When viewing the report in the collapsed mode the label signifying where
did the execution go is often necessary for properly understanding the
context.
Differential Revision: https://reviews.llvm.org/D43145
llvm-svn: 325975
The checker marks the locations where the analyzer creates sinks. However, it
can happen that the sink was created because of a loop which does not contain
condition statement, only breaks in the body. The exhausted block is the block
which should contain the condition but empty, in this case.
This change only emits this marking in order to avoid the undefined behavior.
Differential Revision: https://reviews.llvm.org/D42266
llvm-svn: 325693
Array destructors, like constructors, need to be called for each element of the
array separately. We do not have any mechanisms to do this in the analyzer,
so for now all we do is evaluate a single constructor or destructor
conservatively and give up. It automatically causes the necessary invalidation
and pointer escape for the whole array, because this is how RegionStore works.
Implement this conservative behavior for temporary destructors. This fixes the
crash on the provided test.
Differential Revision: https://reviews.llvm.org/D43149
llvm-svn: 325286
Temporary destructors fire at the end of the full-expression. It is reasonable
to attach the path note for entering/leaving the temporary destructor to its
CXXBindTemporaryExpr. This would not affect lifetime-extended temporaries with
their automatic destructors which aren't temporary destructors.
The path note may be confusing in the case of destructors after elidable copy
constructors.
Differential Revision: https://reviews.llvm.org/D43144
llvm-svn: 325284
Inline them if possible - a separate flag is added to control this.
The whole thing is under the cfg-temporary-dtors flag, off by default so far.
Temporary destructors are called at the end of full-expression. If the
temporary is lifetime-extended, automatic destructors kick in instead,
which are not addressed in this patch, and normally already work well
modulo the overally broken support for lifetime extension.
The patch operates by attaching the this-region to the CXXBindTemporaryExpr in
the program state, and then recalling it during destruction that was triggered
by that CXXBindTemporaryExpr. It has become possible because
CXXBindTemporaryExpr is part of the construction context since r325210.
Differential revision: https://reviews.llvm.org/D43104
llvm-svn: 325282
Since r325210, in cfg-temporary-dtors mode, we can rely on the CFG to tell us
that we're indeed constructing a temporary, so we can trivially construct a
temporary region and inline the constructor.
Much like r325202, this is only done under the off-by-default
cfg-temporary-dtors flag because the temporary destructor, even if available,
will not be inlined and won't have the correct object value (target region).
Unless this is fixed, it is quite unsafe to inline the constructor.
If the temporary is lifetime-extended, the destructor would be an automatic
destructor, which would be evaluated with a "correct" target region - modulo
the series of incorrect relocations performed during the lifetime extension.
It means that at least, values within the object are guaranteed to be properly
escaped or invalidated.
Differential Revision: https://reviews.llvm.org/D43062
llvm-svn: 325211
Constructors of C++ temporary objects that have destructors now can be queried
to discover that they're indeed constructing temporary objects.
The respective CXXBindTemporaryExpr, which is also repsonsible for destroying
the temporary at the end of full-expression, is now available at the
construction site in the CFG. This is all the context we need to provide for
temporary objects that are not lifetime extended. For lifetime-extended
temporaries, more context is necessary.
Differential Revision: https://reviews.llvm.org/D43056
llvm-svn: 325210
EvalCallOptions were introduced in r324018 for allowing various parts of
ExprEngine to notify the inlining mechanism, while preparing for evaluating a
function call, of possible difficulties with evaluating the call that they
foresee. Then mayInlineCall() would still be a single place for making the
decision.
Use that mechanism for destructors as well - pass the necessary flags from the
CFG-element-specific destructor handlers.
Part of this patch accidentally leaked into r324018, which led into a change in
tests; this change is reverted now, because even though the change looked
correct, the underlying behavior wasn't. Both of these commits were not intended
to introduce any function changes otherwise.
Differential Revision: https://reviews.llvm.org/D42991
llvm-svn: 325209
This only affects the cfg-temporary-dtors mode - in this mode we begin inlining
constructors that are constructing function return values. These constructors
have a correct construction context since r324952.
Because temporary destructors are not only never inlined, but also don't have
the correct target region yet, this change is not entirely safe. But this
will be fixed in the subsequent commits, while this stays off behind the
cfg-temporary-dtors flag.
Lifetime extension for return values is still not modeled correctly.
Differential Revision: https://reviews.llvm.org/D42875
llvm-svn: 325202
See reviews.llvm.org/M1 for evaluation, and
lists.llvm.org/pipermail/cfe-dev/2018-January/056718.html for
discussion.
Differential Revision: https://reviews.llvm.org/D42775
llvm-svn: 324956
When the current function returns a C++ object by value, CFG elements for
constructors that construct the return values can now be queried to discover
that they're indeed participating in construction of the respective return value
at the respective return statement.
Differential Revision: https://reviews.llvm.org/D42875
llvm-svn: 324952
It was introduced when two -analyzer-config options were added almost
simultaneously in r324793 and r324668 and the option count was not
rebased correctly in the tests.
Fixes the buildbots.
llvm-svn: 324801
Now that we make it possible to query the CFG constructor element to find
information about the construction site, possible cleanup work represented by
ExprWithCleanups should not prevent us from providing this information.
This allows us to have a correct construction context for variables initialized
"by value" via elidable copy-constructors, such as 'i' in
iterator i = vector.begin();
Differential Revision: https://reviews.llvm.org/D42719
llvm-svn: 324798
CFG elements for constructors of fields and base classes that are being
initialized before the body of the whole-class constructor starts can now be
queried to discover that they're indeed participating in initialization of their
respective fields or bases before the whole-class constructor kicks in.
CFG construction contexts are now capable of representing CXXCtorInitializer
triggers, which aren't considered to be statements in the Clang AST.
Differential Revision: https://reviews.llvm.org/D42700
llvm-svn: 324796
Constructors of simple variables now can be queried to discover that they're
constructing into simple variables.
Differential Revision: https://reviews.llvm.org/D42699
llvm-svn: 324794
This expression may or may not be evaluated in compile time, so tracking the
result symbol is of potential interest. However, run-time offsetof is not yet
supported by the analyzer, so for now this callback is only there to assist
future implementation.
Patch by Henry Wong!
Differential Revision: https://reviews.llvm.org/D42300
llvm-svn: 324790
This builtin is evaluated in compile time. But in the analyzer we don't yet
automagically evaluate all calls that can be evaluated in compile time.
Patch by Felix Kostenzer!
Differential Revision: https://reviews.llvm.org/D42745
llvm-svn: 324789
Even though most of the inconsistencies in MallocChecker's bug categories were
fixed in r302016, one more was introduced in r301913 which was later missed.
Patch by Henry Wong!
Differential Revision: https://reviews.llvm.org/D43074
llvm-svn: 324680
This patch adds a new CFGStmt sub-class, CFGConstructor, which replaces
the regular CFGStmt with CXXConstructExpr in it whenever the CFG has additional
information to provide regarding what sort of object is being constructed.
It is useful for figuring out what memory is initialized in client of the
CFG such as the Static Analyzer, which do not operate by recursive AST
traversal, but instead rely on the CFG to provide all the information when they
need it. Otherwise, the statement that triggers the construction and defines
what memory is being initialized would normally occur after the
construct-expression, and the client would need to peek to the next CFG element
or use statement parent map to understand the necessary facts about
the construct-expression.
As a proof of concept, CFGConstructors are added for new-expressions
and the respective test cases are provided to demonstrate how it works.
For now, the only additional data contained in the CFGConstructor element is
the "trigger statement", such as new-expression, which is the parent of the
constructor. It will be significantly expanded in later commits. The additional
data is organized as an auxiliary structure - the "construction context",
which is allocated separately from the CFGElement.
Differential Revision: https://reviews.llvm.org/D42672
llvm-svn: 324668
It makes it easier to discriminate between values of similar expressions
in different stack frames.
It also makes the separate backtrace section in ExplodedGraph dumps redundant.
Differential Revision: https://reviews.llvm.org/D42552
llvm-svn: 324660
Due to Buildbot failures - most likely that's because target triples were not
specified in the tests, even though the checker behaves differently with
different target triples.
llvm-svn: 324167
This is a security check which is disabled by default but will be enabled
whenever the user consciously enables the security package. If mmap()ed memory
is both writable and executable, it makes it easier for the attacker to execute
arbitrary code when contents of this memory are compromised. Some applications
require such mmap()s though, such as different sorts of JIT.
Patch by David Carlier!
Differential Revision: https://reviews.llvm.org/D42645
llvm-svn: 324166
We already suppress such reports for inlined functions, we should then
get the same behavior for macros.
The underlying reason is that the same macro, can be called from many
different contexts, and nullability can only be expected in _some_ of
them.
Assuming that the macro can return null in _all_ of them sometimes leads
to a large number of false positives.
E.g. consider the test case for the dynamic cast implementation in
macro: in such cases, the bug report is unwanted.
Tracked in rdar://36304776
Differential Revision: https://reviews.llvm.org/D42404
llvm-svn: 324161
If the return statement is stored, we might as well allow querying
against it.
Also fix the bug where the return statement is not stored
if there is no return value.
This change un-merges two ExplodedNodes during call exit when the state
is otherwise identical - the CallExitBegin node itself and the "Bind
Return Value"-tagged node.
And expose the return statement through
getStatement helper function.
Differential Revision: https://reviews.llvm.org/D42130
llvm-svn: 324052
We use CXXTempObjectRegion exclusively as a bailout value for construction
targets when we are unable to find the correct construction region.
Sometimes it works correctly, but rather accidentally than intentionally.
Now that we want to increase the amount of situations where it works correctly,
the first step is to introduce a different way of communicating our failure
to find the correct construction region. EvalCallOptions are introduced
for this purpose.
For now EvalCallOptions are communicating two kinds of problems:
- We have been completely unable to find the correct construction site.
- We have found the construction site correctly, and there's more than one of
them (i.e. array construction which we currently don't support).
Accidentally find and fix a test in which the new approach to communicating
failures produces better results.
Differential Revision: https://reviews.llvm.org/D42457
llvm-svn: 324018
Do not attempt to get the pointee of void* while generating a bug report
(otherwise it will trigger an assert inside RegionStoreManager::getBinding
assert(!T->isVoidType() && "Attempting to dereference a void pointer!")).
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D42396
llvm-svn: 323382
In order to provide more test coverage for inlined operator new(), add more
run-lines to existing test cases, which would trigger our fake header
to provide a body for operator new(). Most of the code should still behave
reasonably. When behavior intentionally changes, #ifs are provided.
Differential Revision: https://reviews.llvm.org/D42221
llvm-svn: 323376
This allows the analyzer to analyze ("inline") custom operator new() calls and,
even more importantly, inline constructors of objects that were allocated
by any operator new() - not necessarily a custom one.
All changes in the tests in the current commit are intended improvements,
even if they didn't carry any explicit FIXME flag.
It is possible to restore the old behavior via
-analyzer-config c++-allocator-inlining=false
(this flag is supported by scan-build as well, and it can be into a clang
--analyze invocation via -Xclang .. -Xclang ..). There is no intention to
remove the old behavior for now.
Differential Revision: https://reviews.llvm.org/D42219
rdar://problem/12180598
llvm-svn: 323373
I.e. not after. In the c++-allocator-inlining=true mode, we need to make the
assumption that the conservatively evaluated operator new() has returned a
non-null value. Previously we did this on CXXNewExpr, but now we have to do that
before calling the constructor, because some clever constructors are sometimes
assuming that their "this" is null and doing weird stuff. We would also crash
upon evaluating CXXNewExpr when the allocator was inlined and returned null and
had a throw specification; this is UB even for custom allocators, but we still
need not to crash.
Added more FIXME tests to ensure that eventually we fix calling the constructor
for null return values.
Differential Revision: https://reviews.llvm.org/D42192
llvm-svn: 323370
Fix an assertion failure caused by a missing CheckName. The malloc checker
enables "basic" support in the CStringChecker, which causes some CString
bounds checks to be enabled. In this case, make sure that we have a
valid CheckName for the BugType.
llvm-svn: 323052
PreStmt<CXXNewExpr> was never called.
Additionally, under c++-allocator-inlining=true, PostStmt<CXXNewExpr> was
called twice when the allocator was inlined: once after evaluating the
new-expression itself, once after evaluating the allocator call which, for the
lack of better options, uses the new-expression as the call site.
This patch fixes both problems.
Differential Revision: https://reviews.llvm.org/D41934
rdar://problem/12180598
llvm-svn: 322797
Add PostAllocatorCall program point to represent the moment in the analysis
between the operator new() call and the constructor call. Pointer cast from
"void *" to the correct object pointer type has already happened by this point.
The new program point, unlike the previously used PostImplicitCall, contains a
reference to the new-expression, which allows adding path diagnostics over it.
Differential Revision: https://reviews.llvm.org/D41800
rdar://problem/12180598
llvm-svn: 322796
Pointer escape event notifies checkers that a pointer can no longer be reliably
tracked by the analyzer. For example, if a pointer is passed into a function
that has no body available, or written into a global, MallocChecker would
no longer report memory leaks for such pointer.
In case of operator new() under -analyzer-config c++-allocator-inlining=true,
MallocChecker would start tracking the pointer allocated by operator new()
only to immediately meet a pointer escape event notifying the checker that the
pointer has escaped into a constructor (assuming that the body of the
constructor is not available) and immediately stop tracking it. Even though
it is theoretically possible for such constructor to put "this" into
a global container that would later be freed, we prefer to preserve the old
behavior of MallocChecker, i.e. a memory leak warning, in order to
be able to find any memory leaks in C++ at all. In fact, c++-allocator-inlining
*reduces* the amount of false positives coming from this-pointers escaping in
constructors, because it'd be able to inline constructors in some cases.
With other checkers working similarly, we simply suppress the escape event for
this-value of the constructor, regardless of analyzer options.
Differential Revision: https://reviews.llvm.org/D41797
rdar://problem/12180598
llvm-svn: 322795
Implements finding appropriate source locations for intermediate diagnostic
pieces in path-sensitive bug reports that need to descend into an inlined
operator new() call that was called via new-expression. The diagnostics have
worked correctly when operator new() was called "directly".
Differential Revision: https://reviews.llvm.org/D41409
rdar://problem/12180598
llvm-svn: 322791
Fix the const qualifier so that the operator defined in the tests indeed does
override the default global nothrow version of new.
Differential Revision: https://reviews.llvm.org/D41408
llvm-svn: 322790
The callback runs after operator new() and before the construction and allows
the checker to access the casted return value of operator new() (in the
sense of r322780) which is not available in the PostCall callback for the
allocator call.
Update MallocChecker to use the new callback instead of PostStmt<CXXNewExpr>,
which gets called after the constructor.
Differential Revision: https://reviews.llvm.org/D41406
rdar://problem/12180598
llvm-svn: 322787
Make sure that with c++-allocator-inlining=true we have the return value of
conservatively evaluated operator new() in the correct memory space (heap).
This is a regression/omission that worked well in c++-allocator-inlining=false.
Heap regions are superior to regular symbolic regions because they have
stricter aliasing constraints: heap regions do not alias each other or global
variables.
Differential Revision: https://reviews.llvm.org/D41266
rdar://problem/12180598
llvm-svn: 322780
According to [basic.stc.dynamic.allocation], the return type of any C++
overloaded operator new() is "void *". However, type of the new-expression
"new T()" and the type of "this" during construction of "T" are both "T *".
Hence an implicit cast, which is not present in the AST, needs to be performed
before the construction. This patch adds such cast in the case when the
allocator was indeed inlined. For now, in the case where the allocator was *not*
inlined we still use the same symbolic value (which is a pure SymbolicRegion of
type "T *") because it is consistent with how we represent the casts and causes
less surprise in the checkers after switching to the new behavior.
The better approach would be to represent that value as a cast over a
SymbolicRegion of type "void *", however we have technical difficulties
conjuring such region without any actual expression of type "void *" present in
the AST.
Differential Revision: https://reviews.llvm.org/D41250
rdar://problem/12180598
llvm-svn: 322777
The -analyzer-config c++-allocator-inlining experimental option allows the
analyzer to reason about C++ operator new() similarly to how it reasons about
regular functions. In this mode, operator new() is correctly called before the
construction of an object, with the help of a special CFG element.
However, the subsequent construction of the object was still not performed into
the region of memory returned by operator new(). The patch fixes it.
Passing the value from operator new() to the constructor and then to the
new-expression itself was tricky because operator new() has no call site of its
own in the AST. The new expression itself is not a good call site because it
has an incorrect type (operator new() returns 'void *', while the new expression
is a pointer to the allocated object type). Additionally, lifetime of the new
expression in the environment makes it unsuitable for passing the value.
For that reason, an additional program state trait is introduced to keep track
of the return value.
Finally this patch relaxes restrictions on the memory region class that are
required for inlining the constructor. This change affects the old mode as well
(c++-allocator-inlining=false) and seems safe because these restrictions were
an overkill compared to the actual problems observed.
Differential Revision: https://reviews.llvm.org/D40560
rdar://problem/12180598
llvm-svn: 322774
HTML diagnostics can be an overwhelming blob of pages of code.
This patch adds a checkbox which filters this list down to only the
lines *relevant* to the counterexample by e.g. skipping branches which
analyzer has assumed to be infeasible at a time.
The resulting amount of output is much smaller, and often fits on one
screen, and also provides a much more readable diagnostics.
Differential Revision: https://reviews.llvm.org/D41378
llvm-svn: 322612
In the security package, we have a simple syntactic check that warns about
strcpy() being insecure, due to potential buffer overflows.
Suppress that check's warning in the trivial situation when the source is an
immediate null-terminated string literal and the target is an immediate
sufficiently large buffer.
Patch by András Leitereg!
Differential Revision: https://reviews.llvm.org/D41384
llvm-svn: 322410
The current code used to not suppress the report, if the dereference was
performed in a macro, assuming it is that same macro.
However, the assumption might not be correct, and XNU has quite a bit of
code where dereference is actually performed in a different macro.
As the code uses macro name and not a unique identifier it might be fragile,
but in a worst-case scenario we would simply emit an extra diagnostic.
rdar://36160245
Differential Revision: https://reviews.llvm.org/D41749
llvm-svn: 322149
This addresses an issue introduced in r183451: since
`removePiecesWithInvalidLocations` is called *after* `adjustCallLocations`,
it is not necessary, and in fact harmful, to have this assertion in
adjustCallLocations.
Addresses rdar://36170689
Differential Revision: https://reviews.llvm.org/D41680
llvm-svn: 321682
Using ARC, strong, weak, and autoreleasing stack variables are implicitly
initialized with nil. This includes variable-length arrays of Objective-C object
pointers. However, in the analyzer we don't zero-initialize them. We used to,
but it accidentally regressed after r289618.
Under ARC, the array variable's initializer within DeclStmt is an
ImplicitValueInitExpr. Environment doesn't maintain any bindings for this
expression kind - instead it always knows that it's a known constant
(0 in our case), so it just returns the known value by calling
SValBuilder::makeZeroVal() (see EnvironmentManager::getSVal().
Commit r289618 had introduced reasonable behavior of SValBuilder::makeZeroVal()
for the arrays, which produces a zero-length compoundVal{}. When such value
is bound to arrays, in RegionStoreManager::bindArray() "remaining" items in the
array are default-initialized with zero, as in
RegionStoreManager::setImplicitDefaultValue(). The similar mechanism works when
an array is initialized by an initializer list that is too short, eg.
int a[3] = { 1, 2 };
would result in a[2] initialized with 0. However, in case of variable-length
arrays it didn't know if any more items need to be added,
because, well, the length is variable.
Add the default binding anyway, regardless of how many actually need
to be added. We don't really care how many, because the default binding covers
the whole array anyway.
Differential Revision: https://reviews.llvm.org/D41478
rdar://problem/35477763
llvm-svn: 321290
The bugreporter::trackNullOrUndefValue() mechanism contains a system of bug
reporter visitors that recursively call each other in order to track where a
null or undefined value came from, where each visitor represents a particular
tracking mechanism (track how the value was stored, track how the value was
returned from a function, track how the value was constrained to null, etc.).
Each visitor is only added once per value it needs to track. Almost. One
exception from this rule would be FindLastStoreBRVisitor that has two operation
modes: it contains a flag that indicates whether null stored values should be
suppressed. Two instances of FindLastStoreBRVisitor with different values of
this flag are considered to be different visitors, so they can be added twice
and produce the same diagnostic twice. This was indeed the case in the affected
test.
With the current logic of this whole machinery, such duplication seems
unavoidable. We should be able to safely add visitors with different flag
values without constructing duplicate diagnostic pieces. Hence the effort
in this commit to de-duplicate diagnostics regardless of what visitors
have produced them.
Differential Revision: https://reviews.llvm.org/D41258
llvm-svn: 321135
When trying to figure out where a null or undefined value came from,
parentheses and cast expressions are either completely irrelevant, or,
in the case of lvalue-to-rvale cast, straightforwardly lead us in the right
direction when we remove them.
There is a regression that causes a certain diagnostic to appear twice in the
path-notes.cpp test (changed to FIXME). It would be addressed in the next
commit.
Differential revision: https://reviews.llvm.org/D41254
llvm-svn: 321133
When reporting certain kinds of analyzer warnings, we use the
bugreporter::trackNullOrUndefValue mechanism, which is part of public checker
API, to understand where a zero, null-pointer, or garbage value came from,
which would highlight important events with respect to that value in the
diagnostic path notes, and help us suppress various false positives that result
from values appearing from particular sources.
Previously, we've lost track of the value when it was written into a memory
region that is not a plain variable. Now try to resume tracking in this
situation by finding where the last write to this region has occured.
Differential revision: https://reviews.llvm.org/D41253
llvm-svn: 321130
Since C++17, classes that have base classes can potentially be initialized as
aggregates. Trying to construct such objects through brace initialization was
causing the analyzer to crash when the base class has a non-trivial constructor,
while figuring target region for the base class constructor, because the parent
stack frame didn't contain the constructor of the subclass, because there is
no constructor for subclass, merely aggregate initialization.
This patch avoids the crash, but doesn't provide the actually correct region
for the constructor, which still remains to be fixed. Instead, construction
goes into a fake temporary region which would be immediately discarded. Similar
extremely conservative approach is used for other cases in which the logic for
finding the target region is not yet implemented, including aggregate
initialization with fields instead of base-regions (which is not C++17-specific
but also never worked, just didn't crash).
Differential revision: https://reviews.llvm.org/D40841
rdar://problem/35441058
llvm-svn: 321128
The new check introduced in r318705 is useful, but suffers from a particular
class of false positives, namely, it does not account for
dispatch_barrier_sync() API which allows one to ensure that the asyncronously
executed block that captures a pointer to a local variable does not actually
outlive that variable.
The new check is split into a separate checker, under the name of
alpha.core.StackAddressAsyncEscape, which is likely to get enabled by default
again once these positives are fixed. The rest of the StackAddressEscapeChecker
is still enabled by default.
Differential Revision: https://reviews.llvm.org/D41042
llvm-svn: 320455
Array subscript is almost always an lvalue, except for a few cases where
it is not, such as a subscript into an Objective-C property, or a
return from the function.
This commit prevents crashing in such cases.
Fixes rdar://34829842
Differential Revision: https://reviews.llvm.org/D40584
llvm-svn: 319834
RegionStore has special logic to evaluate captured constexpr variables.
However, if the constexpr initializer cannot be evaluated as an integer, the
value is treated as undefined. This leads to false positives when, for example,
a constexpr float is captured by a lambda.
To fix this, treat a constexpr capture that cannot be evaluated as unknown
rather than undefined.
rdar://problem/35784662
llvm-svn: 319638
In the original design of the analyzer, it was assumed that a BlockEntrance
doesn't create a new binding on the Store, but this assumption isn't true when
'widen-loops' is set to true. Fix this by finding an appropriate location
BlockEntrace program points.
Patch by Henry Wong!
Differential Revision: https://reviews.llvm.org/D37187
llvm-svn: 319333
We didn't support the following syntax:
(std::initializer_list<int>){12}
which suddenly produces CompoundLiteralExpr that contains
CXXStdInitializerListExpr.
Lift the assertion and instead pass the value through CompoundLiteralExpr
transparently, as it doesn't add much.
Differential Revision: https://reviews.llvm.org/D39803
llvm-svn: 319058
We were crashing whenever a C++ pointer-to-member was taken, that was pointing
to a member of an anonymous structure field within a class, eg.
struct A {
struct {
int x;
};
};
// ...
&A::x;
Differential Revision: https://reviews.llvm.org/D39800
llvm-svn: 319055
Teach the retain-count checker that CoreMedia reference types use
CoreFoundation-style reference counting. This enables the checker
to catch leaks and over releases of those types.
rdar://problem/33599757
llvm-svn: 318979
CFG wass built in non-deterministic order due to the fact that indirect
goto labels' declarations (LabelDecl's) are stored in the llvm::SmallSet
container. LabelDecl's are pointers, whose order is not deterministic,
and llvm::SmallSet sorts them by their non-deterministic addresses after
"small" container is exceeded. This leads to non-deterministic processing
of the elements of the container.
The fix is to use llvm::SmallSetVector that was designed to have
deterministic iteration order.
Patch by Ilya Palachev!
Differential Revision: https://reviews.llvm.org/D40073
llvm-svn: 318754
CFG wass built in non-deterministic order due to the fact that indirect
goto labels' declarations (LabelDecl's) are stored in the llvm::SmallSet
container. LabelDecl's are pointers, whose order is not deterministic,
and llvm::SmallSet sorts them by their non-deterministic addresses after
"small" container is exceeded. This leads to non-deterministic processing
of the elements of the container.
The fix is to use llvm::SmallSetVector that was designed to have
deterministic iteration order.
Patch by Ilya Palachev!
Differential Revision: https://reviews.llvm.org/D40073
llvm-svn: 318750
This diff extends StackAddrEscapeChecker
to catch stack addresses leaks via block captures
if the block is executed asynchronously or
returned from a function.
Differential revision: https://reviews.llvm.org/D39438
llvm-svn: 318705
The ObjCGenerics checker warns on a cast when there is no subtyping relationship
between the tracked type of the value and the destination type of the cast. It
does this even if the cast was explicitly written. This means the user can't
write an explicit cast to silence the diagnostic.
This commit treats explicit casts involving generic types as an indication from
the programmer that the Objective-C type system is not rich enough to express
the needed invariant. On explicit casts, the checker now removes any existing
information inferred about the type arguments. Further, it no longer assumes
the casted-to specialized type because the invariant the programmer specifies
in the cast may only hold at a particular program point and not later ones. This
prevents a suppressing cast from requiring a cascade of casts down the
line.
rdar://problem/33603303
Differential Revision: https://reviews.llvm.org/D39711
llvm-svn: 318054
This is the issue breaking the postgresql bot, purely by chance exposed
through taint checker, somehow appearing after
https://reviews.llvm.org/D38358 got committed.
The backstory is that the taint checker requests SVal for the value of
the pointer, and analyzer has a "fast path" in the getter to return a
constant when we know that the value is constant.
Unfortunately, the getter requires a cast to get signedness correctly,
and for the pointer `void *` the cast crashes.
This is more of a band-aid patch, as I am not sure what could be done
here "correctly", but it should be applied in any case to avoid the
crash.
Differential Revision: https://reviews.llvm.org/D39862
llvm-svn: 317839
Patches the solver to assume that bitwise OR of an unsigned value with a
constant always produces a value larger-or-equal than the constant, and
bitwise AND with a constant always produces a value less-or-equal than
the constant.
This patch is especially useful in the context of using bitwise
arithmetic for error code encoding: the analyzer would be able to state
that the error code produced using a bitwise OR is non-zero.
Differential Revision: https://reviews.llvm.org/D39707
llvm-svn: 317820
Do not crash when trying to compute x && y or x || y where x and y are
of a vector type.
For now we do not seem to properly model operations with vectors. In particular,
operations && and || on a pair of vectors are not short-circuit, unlike regular
logical operators, so even our CFG is incorrect.
Avoid the crash, add respective FIXME tests for later.
Differential Revision: https://reviews.llvm.org/D39682
rdar://problem/34317663
llvm-svn: 317700
Do not crash when trying to define and call a non-standard
strcpy(unsigned char *, unsigned char *) during analysis.
At the same time, do not try to actually evaluate the call.
Differential Revision: https://reviews.llvm.org/D39422
llvm-svn: 317565
The analyzer's BodyFarm models dispatch_once() by comparing the passed-in
predicate against a known 'done' value. If the predicate does not have that
value, the model updates the predicate to have that value and executes the
passed in block.
Unfortunately, the current model uses the wrong 'done' value: 1 instead of ~0.
This interferes with libdispatch's static inline function _dispatch_once(),
which enables a fast path if the block has already been executed. That function
uses __builtin_assume() to tell the compiler that the done flag is set to ~0 on
exit. When r302880 added modeling of __builtin_assume(), this caused the
analyzer to assume 1 == ~0. This in turn caused the analyzer to never explore any code after a call to dispatch_once().
This patch regains the missing coverage by updating BodyFarm to use the correct
'done' value.
rdar://problem/34413048
Differential Revision: https://reviews.llvm.org/D39691
llvm-svn: 317516
The analyzer did not return an UndefVal in case a negative value was left
shifted. I also altered the UndefResultChecker to emit a clear warning in this
case.
Differential Revision: https://reviews.llvm.org/D39423
llvm-svn: 316924
Now when a template is instantiated more times and there is a bug found in the
instantiations the issue hash will be different for each instantiation even if
every other property of the bug (path, message, location) is the same.
This patch aims to resolve this issue. Note that explicit specializations still
generate different hashes but that is intended.
Differential Revision: https://reviews.llvm.org/D38728
llvm-svn: 316900
Extend ExprInspection checker to make it possible to dump the issue hash of
arbitrary expressions. This change makes it possible to make issue hash related
tests more concise and also makes debugging issue hash related problems easier.
Differential Revision: https://reviews.llvm.org/D38844
llvm-svn: 316899
Added new enum in order to differentiate the warning messages on "misusing" into
3 categories: function calls, moving an object, copying an object. (At the
moment the checker gives the same message in case of copying and moving.)
Additional test cases added as well.
Differential Revision: https://reviews.llvm.org/D38674
llvm-svn: 316852
An earlier solution from Artem r315301 solves the reset problem, however, the
reports should be handled the same way in case of method calls. We should not
just report the base class of the object where the method was defined but the
whole object.
Fixed false positive which came from not removing the subobjects in case of a
state-resetting function. (Just replaced the State->remove(...) call to
removeFromState(..) which was defined exactly for that purpose.)
Some minor typos fixed in this patch as well which did not worth a whole new
patch in my opinion, so included them here.
Differential Revision: https://reviews.llvm.org/D31538
llvm-svn: 316850
OpaqueValueExpr in a GNU binary conditional expression.
It's not meaningful for a non-materialized temporary object to be used as a
common subexpression of multiple expressions.
llvm-svn: 316836
The loop unrolling feature aims to track the maximum possible steps a loop can
make. In order to implement this, it investigates the initial value of the
counter variable and the bound number. (It has to be known.)
These numbers are used as llvm::APInts, however, it was not checked if their
bitwidths are the same which lead to some crashes.
This revision solves this problem by extending the "shorter" one (to the length
of the "longer" one).
For the detailed bug report, see: https://bugs.llvm.org/show_bug.cgi?id=34943
Differential Revision: https://reviews.llvm.org/D38922
llvm-svn: 316830
In getLValueElement Base may represent the address of a label
(as in the newly-added test case), in this case it's not a loc::MemRegionVal
and Base.castAs<loc::MemRegionVal>() triggers an assert, this diff makes
getLValueElement return UnknownVal instead.
Differential revision: https://reviews.llvm.org/D39174
llvm-svn: 316399
Remove an option to use a reference type (on by default!) since a
non-reference type is always needed for creating expressions, functions
with multiple boolean parameters are very hard to use, and in general it
was just a booby trap for further crashes.
Furthermore, generalize call_once test case to fix some of the crashes mentioned
https://bugs.llvm.org/show_bug.cgi?id=34869
Also removes std::call_once crash.
Differential Revision: https://reviews.llvm.org/D39015
llvm-svn: 316041
The first attempt, rL315614 was reverted because one libcxx
test broke, and i did not know at the time how to deal with it.
Summary:
Currently, clang only diagnoses completely out-of-range comparisons (e.g. `char` and constant `300`),
and comparisons of unsigned and `0`. But gcc also does diagnose the comparisons with the
`std::numeric_limits<>::max()` / `std::numeric_limits<>::min()` so to speak
Finally Fixes https://bugs.llvm.org/show_bug.cgi?id=34147
Continuation of https://reviews.llvm.org/D37565
Reviewers: rjmccall, rsmith, aaron.ballman
Reviewed By: rsmith
Subscribers: rtrieu, jroelofs, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D38101
llvm-svn: 315875
In some cases the analyzer didn't expect an array-type variable to be
initialized with anything other than a string literal. The patch essentially
removes the assertion, and ensures relatively sane behavior.
There is a bigger problem with these initializers. Currently our memory model
(RegionStore) is being ordered to initialize the array with a region that
is assumed to be storing the initializer rvalue, and it guesses to copy
the contents of that region to the array variable. However, it would make
more sense for RegionStore to receive the correct initializer in the first
place. This problem isn't addressed with this patch.
rdar://problem/27248428
Differential Revision: https://reviews.llvm.org/D23963
llvm-svn: 315750
The checker used to crash when a mempcpy's length argument is symbolic. In this
case the cast from 'void *' to 'char *' failed because the respective
ElementRegion that represents cast is hard to add on top of the existing
ElementRegion that represents the offset to the last copied byte, while
preseving a sane memory region structure.
Additionally, a few test cases are added (to casts.c) which demonstrate problems
caused by existing sloppy work we do with multi-layer ElementRegions. If said
cast would be modeled properly in the future, these tests would need to be
taken into account.
Differential Revision: https://reviews.llvm.org/D38797
llvm-svn: 315742
It is not uncommon for the users to make their own wrappers around
CoreFoundation's CFRetain and CFRelease functions that are defensive
against null references. In such cases CFRetain is often incorrectly
marked as CF_RETURNS_RETAINED. Ignore said annotation and treat such
wrappers similarly to the regular CFRetain.
rdar://problem/31699502
Differential Revision: https://reviews.llvm.org/D38877
llvm-svn: 315736
If a method is resetting the state of an object that was moved from, it should
be safe to use this object again. However if the method was defined in a parent
class, but used in a child class, the reset didn't happen from the checker's
perspective.
Differential Revision: https://reviews.llvm.org/D31538
llvm-svn: 315301
The analyzer now realizes that C++ std::initializer_list objects and
Objective-C boxed structure/array/dictionary expressions can potentially
maintain a reference to the objects that were put into them. This avoids
false memory leak posivites and a few other issues.
This is a conservative behavior; for now, we do not model what actually happens
to the objects after being passed into such initializer lists.
rdar://problem/32918288
Differential Revision: https://reviews.llvm.org/D35216
llvm-svn: 314975
In ProgramState::getSVal(Location, Type) API which dereferences a pointer value,
when the optional Type parameter is not supplied and the Location is not typed,
type should have been guessed on a best-effort basis by inspecting the Location
more deeply. However, this never worked; the auto-detected type was instead
a pointer type to the correct type.
Fixed the issue and added various test cases to demonstrate which parts of the
analyzer were affected (uninitialized pointer argument checker, C++ trivial copy
modeling, Google test API modeling checker).
Additionally, autodetected void types are automatically replaced with char,
in order to simplify checker APIs. Which means that if the location is a void
pointer, getSVal() would read the first byte through this pointer
and return its symbolic value.
Fixes pr34305.
Differential Revision: https://reviews.llvm.org/D38358
llvm-svn: 314910
Fixes the test failure: temporary is now bound to std::string, tests
fully pass on Linux.
This reverts commit b36ee0924038e1d95ea74230c62d46e05f80587e.
llvm-svn: 314859
Only assume that IOBSDNameMatching and friends increment a reference counter
if their return type is a CFMutableDictionaryRef.
Differential Revision: https://reviews.llvm.org/D38487
llvm-svn: 314820
This function can now track null pointer through simple pointer arithmetic,
such as '*&*(p + 2)' => 'p' and so on, displaying intermediate diagnostic pieces
for the user to understand where the null pointer is coming from.
Differential Revision: https://reviews.llvm.org/D37025
llvm-svn: 314290
This API is used by checkers (and other entities) in order to track where does
a value originate from, by jumping from an expression value of which is equal
to that value to the expression from which this value has "appeared". For
example, it may be an lvalue from which the rvalue was loaded, or a function
call from which the dereferenced pointer was returned.
The function now avoids incorrectly unwrapping implicit lvalue-to-rvalue casts,
which caused crashes and incorrect intermediate diagnostic pieces. It also no
longer relies on how the expression is written when guessing what it means.
Fixes pr34373 and pr34731.
rdar://problem/33594502
Differential Revision: https://reviews.llvm.org/D37023
llvm-svn: 314287
This patch fixes analyzer's crash on the newly added test case
(see also https://bugs.llvm.org/show_bug.cgi?id=34374).
Pointers subtraction appears to be modeled incorrectly
in the following example:
char* p;
auto n = p - reinterpret_cast<char*>((unsigned long)1);
In this case the analyzer (built without this patch)
tries to create a symbolic value for the difference
treating reinterpret_cast<char*>((unsigned long)1)
as an integer, that is not correct.
Differential revision: https://reviews.llvm.org/D38214
Test plan: make check-all
llvm-svn: 314141
This patch introduces a class that can help to build tools that require cross
translation unit facilities. This class allows function definitions to be loaded
from external AST files based on an index. In order to use this functionality an
index is required. The index format is a flat text file but it might be
replaced with a different solution in the near future. USRs are used as names to
look up the functions definitions. This class also does caching to avoid
redundant loading of AST files.
Right now only function defnitions can be loaded using this API because this is
what the in progress cross translation unit feature of the Static Analyzer
requires. In to future this might be extended to classes, types etc.
Differential Revision: https://reviews.llvm.org/D34512
llvm-svn: 313975
If a function or variable has a type with no linkage (and is not extern "C"),
any use of it requires a definition within the same translation unit; the idea
is that it is not possible to define the entity elsewhere, so any such use is
necessarily an error.
There is an exception, though: some types formally have no linkage but
nonetheless can be referenced from other translation units (for example, this
happens to anonymous structures defined within inline functions). For entities
with those types, we suppress the diagnostic except under -pedantic.
llvm-svn: 313729
overridden methods when compiling for non-ARC.
Previously, clang would error out when compiling for ARC, but didn't
print any diagnostics when compiling for non-ARC.
This was pointed out in the patch review for attribute noescape:
https://reviews.llvm.org/D32210
llvm-svn: 313717
Summary:
So far we used a value of 10 which was useful for testing but produces many false-positives in real programs. The usual suspicious clones we find seem to be at around a complexity value of 70 and for normal clone-reporting everything above 50 seems to be a valid normal clone for users, so let's just go with 50 for now and set this as the new default value.
This patch also explicitly sets the complexity value for the regression tests as they serve more of a regression testing/debugging purpose and shouldn't really be reported by default in real programs. I'll add more tests that reflect actual found bugs that then need to pass with the default setting in the future.
Reviewers: NoQ
Subscribers: cfe-commits, javed.absar, xazax.hun, v.g.vassilev
Differential Revision: https://reviews.llvm.org/D34178
llvm-svn: 312468
Replace "long" with __UINTPTR_TYPE__
to make the test added in rL311935 Windows-friendly.
Caught by the buildbot llvm-clang-x86_64-expensive-checks-win.
llvm-svn: 311947
This diff fixes modeling of arithmetic
expressions where pointers are treated as integers
(i.e. via C-style / reinterpret casts).
For now we return UnknownVal unless the operation is a comparison.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D37120
llvm-svn: 311935
This way the unrolling can be restricted for loops which will take at most a
given number of steps. It is defined as 128 in this patch and it seems to have
a good number for that purpose.
Differential Revision: https://reviews.llvm.org/D37181
llvm-svn: 311883
Added check if the execution of the last step of the given unrolled loop has
generated more branches. If yes, than treat it as a normal (non-unrolled) loop
in the remaining part of the analysis.
Differential Revision: https://reviews.llvm.org/D36962
llvm-svn: 311881
1. The LoopUnrolling feature needs the LoopExit included in the CFG so added this
dependency via the config options
2. The LoopExit element can be encountered even if we haven't encountered the
block of the corresponding LoopStmt. So the asserts were not right.
3. If we are caching out the Node then we get a nullptr from generateNode which
case was not handled.
Differential Revision: https://reviews.llvm.org/D37103
llvm-svn: 311880
The LoopExit CFG information provides the opportunity to not mark the loops but
having a stack which tracks if a loop is unrolled or not. So in case of
simulating a loop we just add it and the information if it meets the
requirements to be unrolled to the top of the stack.
Differential Revision: https://reviews.llvm.org/D35684
llvm-svn: 311346
This patch introduces a new CFG element CFGLoopExit that indicate when a loop
ends. It does not deal with returnStmts yet (left it as a TODO).
It hidden behind a new analyzer-config flag called cfg-loopexit (false by
default).
Test cases added.
The main purpose of this patch right know is to make loop unrolling and loop
widening easier and more efficient. However, this information can be useful for
future improvements in the StaticAnalyzer core too.
Differential Revision: https://reviews.llvm.org/D35668
llvm-svn: 311235
Adding escape check for the counter variable of the loop.
It is achieved by jumping back on the ExplodedGraph to its declStmt.
Differential Revision: https://reviews.llvm.org/D35657
llvm-svn: 311234
This diff fixes analyzer's crash (triggered assert) on the newly added test case.
The assert being discussed is assert(!B.lookup(R, BindingKey::Direct))
in lib/StaticAnalyzer/Core/RegionStore.cpp, however the root cause is different.
For classes with empty bases the offsets might be tricky.
For example, let's assume we have
struct S: NonEmptyBase, EmptyBase {
...
};
In this case Clang applies empty base class optimization and
the offset of EmptyBase will be 0, it can be verified via
clang -cc1 -x c++ -v -fdump-record-layouts main.cpp -emit-llvm -o /dev/null.
When the analyzer tries to perform zero initialization of EmptyBase
it will hit the assert because that region
has already been "written" by the constructor of NonEmptyBase.
Test plan:
make check-all
Differential revision: https://reviews.llvm.org/D36851
llvm-svn: 311182
This commit adds the functionality of performing reference counting on the
callee side for Integer Set Library (ISL) to Clang Static Analyzer's
RetainCountChecker.
Reference counting on the callee side can be extensively used to perform
debugging within a function (For example: Finding leaks on error paths).
Patch by Malhar Thakkar!
Differential Revision: https://reviews.llvm.org/D36441
llvm-svn: 311063
The %T lit expansion expands to a common directory shared between all the tests in the same directory, which is unexpected and unintuitive, and more importantly, it's been a source of subtle race conditions and flaky tests. In https://reviews.llvm.org/D35396, it was agreed that it would be best to simply ban %T and only keep %t, which is unique to each test. When a test needs a temporary directory, it can just create one using mkdir %t.
This patch removes %T in clang.
Differential Revision: https://reviews.llvm.org/D36437
llvm-svn: 310950
This diff fixes a crash (triggered assert) on the newly added test case.
In the method Simplifier::VisitSymbolData we check the type of S and return
Loc/NonLoc accordingly.
Differential revision: https://reviews.llvm.org/D36564
llvm-svn: 310887
This change adds support for cross-file diagnostic paths in html output. If the
diagnostic path is not cross-file, there is no change in the output.
Patch by Vlad Tsyrklevich!
Differential Revision: https://reviews.llvm.org/D30406
llvm-svn: 309968
This feature allows the analyzer to consider loops to completely unroll.
New requirements/rules (for unrolling) can be added easily via ASTMatchers.
Right now it is hidden behind a flag, the aim is to find the correct heuristic
and create a solution which results higher coverage % and more precise
analysis, thus can be enabled by default.
Right now the blocks which belong to an unrolled loop are marked by the
LoopVisitor which adds them to the ProgramState.
Then whenever we encounter a CFGBlock in the processCFGBlockEntrance which is
marked then we skip its investigating. That means, it won't be considered to
be visited more than the maximal bound for visiting since it won't be checked.
llvm-svn: 309006
Add a 'Generalized' object kind to the retain-count checker and suitable
generic diagnostic text for retain-count diagnostics involving those objects.
For now the object kind is introduced in summaries by 'annotate' attributes.
Once we have more experience with these annotations we will propose explicit
attributes.
Patch by Malhar Thakkar!
Differential Revision: https://reviews.llvm.org/D35613
llvm-svn: 308990
Because since r308957 the suppress-on-sink feature contains its own
mini-analysis, it also needs to become aware that C++ unhandled exceptions
cause sinks. Unfortunately, for now we treat all exceptions as unhandled in
the analyzer, so suppress-on-sink needs to do the same.
rdar://problem/28157554
Differential Revision: https://reviews.llvm.org/D35674
llvm-svn: 308961
If a certain memory leak (or other similar bug) found by the analyzer is known
to be happening only before abnormal termination of the program ("sink", eg.
assertion failure in the code under analysis, or another bug that introduces
undefined behavior), such leak warning is discarded. However, if the analysis
has never reaches completion (due to complexity of the code), it may be
failing to notice the sink.
This commit further extends the partial solution introduced in r290341 to cover
cases when a complicated control flow occurs before encountering a no-return
statement (which anyway inevitably leads to such statement(s)) by traversing
the respective section of the CFG in a depth-first manner. A complete solution
still seems elusive.
rdar://problem/28157554
Differential Revision: https://reviews.llvm.org/D35673
llvm-svn: 308957
requirements/rules (for unrolling) can be added easily via ASTMatchers.
The current implementation is hidden behind a flag.
Right now the blocks which belong to an unrolled loop are marked by the
LoopVisitor which adds them to the ProgramState. Then whenever we encounter a
CFGBlock in the processCFGBlockEntrance which is marked then we skip its
investigating. That means, it won't be considered to be visited more than the
maximal bound for visiting since it won't be checked.
Differential Revision: https://reviews.llvm.org/D34260
llvm-svn: 308558
Add support to the retain-count checker for an annotation indicating that a
function's implementation should be trusted by the retain count checker.
Functions with these attributes will not be inlined and the arguments will
be treating as escaping.
Adding this annotation avoids spurious diagnostics when the implementation of
a reference counting operation is visible but the analyzer can't reason
precisely about the ref count.
Patch by Malhar Thakkar!
Differential Revision: https://reviews.llvm.org/D34937
llvm-svn: 308416
be shared without warnings. Build AttributedTypes to leave breadcrumbs
for tools like the static analyzer. Warn about attempting to use the
attribute with incompatible return types.
llvm-svn: 308092
There was already a returns_localized_nsstring annotation to indicate
that the return value could be passed to UIKit methods that would
display them. However, those UIKit methods were hard-coded, and it was
not possible to indicate that other classes/methods in a code-base would
do the same.
The takes_localized_nsstring annotation can be put on function
parameters and selector parameters to indicate that those will also show
the string to the user.
Differential Revision: https://reviews.llvm.org/D35186
llvm-svn: 308012
Summary:
This mimics the implementation for the implicit destructors. The
generation of this scope leaving elements is hidden behind
a flag to the CFGBuilder, thus it should not affect existing code.
Currently, I'm missing a test (it's implicitly tested by the clang-tidy
lifetime checker that I'm proposing).
I though about a test using debug.DumpCFG, but then I would
have to add an option to StaticAnalyzer/Core/AnalyzerOptions
to enable the scope leaving CFGElement,
which would only be useful to that particular test.
Any other ideas how I could make a test for this feature?
Reviewers: krememek, jordan_rose
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D15031
llvm-svn: 307759
This is a follow up for one of
the previous diffs https://reviews.llvm.org/D32328.
getTypeSize and with getIntWidth are not equivalent for bool
(see https://clang.llvm.org/doxygen/ASTContext_8cpp_source.html#l08444),
this causes a number of issues
(for instance, if APint X representing a bool is created
with the wrong bit width then X is not comparable against Min/Max
(because of the different bit width), that results in crashes
(triggered asserts) inside assume* methods),
for examples see the newly added test cases.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D35041
llvm-svn: 307604
This is a new checker package. It contains checkers that highlight
well-documented implementation-defined behavior. Such checkers are only useful
to developers that intend to write portable code. Code that is only compiled for
a single platform should be allowed to rely on this platform's specific
documented behavior.
rdar://problem/30545046
Differential Revision: https://reviews.llvm.org/D34102
llvm-svn: 306396
This makes the analyzer around 10% slower by default,
allowing it to find deeper bugs.
Default values for the following -analyzer-config change:
max-nodes: 150000 -> 225000;
max-inlinable-size: 50 -> 100.
rdar://problem/32539666
Differential Revision: https://reviews.llvm.org/D34277
llvm-svn: 305900
Summary: Modify the test infrastructure to properly handle tests that require z3, and merge together the output of all tests on success. This is required for D28954.
Reviewers: dcoughlin, zaks.anna, NoQ, xazax.hun
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33308
llvm-svn: 305480
Memory region allocated by alloca() carries no implicit type information.
Don't crash when resolving the init message for an Objective-C object
that is being constructed in such region.
rdar://problem/32517077
Differential Revision: https://reviews.llvm.org/D33828
llvm-svn: 305211
In plist output mode with alternate path diagnostics, when entering a function,
we draw an arrow from the caller to the beginning of the callee's declaration.
Upon exiting, however, we draw the arrow from the last statement in the
callee function. The former makes little sense when the declaration is
not a definition, i.e. has no body, which may happen in case the body
is coming from a body farm, eg. Objective-C autosynthesized property accessor.
Differential Revision: https://reviews.llvm.org/D33671
llvm-svn: 304713
Nullable-to-nonnull checks used to crash when the custom bug visitor was trying
to add its notes to autosynthesized accessors of Objective-C properties.
Now we avoid this, mostly automatically outside of checker control, by
moving the diagnostic to the parent stack frame where the accessor has been
called.
Differential revision: https://reviews.llvm.org/D32437
llvm-svn: 304710
The analyzer's taint analysis can now reason about structures or arrays
originating from taint sources in which only certain sections are tainted.
In particular, it also benefits modeling functions like read(), which may
read tainted data into a section of a structure, but RegionStore is incapable of
expressing the fact that the rest of the structure remains intact, even if we
try to model read() directly.
Patch by Vlad Tsyrklevich!
Differential revision: https://reviews.llvm.org/D28445
llvm-svn: 304162
The new checker currently contains the very core infrastructure for tracking
the state of iterator-type objects in the analyzer: relating iterators to
their containers, tracking symbolic begin and end iterator values for
containers, and solving simple equality-type constraints over iterators.
A single specific check over this infrastructure is capable of finding usage of
out-of-range iterators in some simple cases.
Patch by Ádám Balogh!
Differential revision: https://reviews.llvm.org/D32592
llvm-svn: 304160
pthread_mutex_destroy() may fail, returning a non-zero error number, and
keeping the mutex untouched. The mutex can be used on the execution branch
that follows such failure, so the analyzer shouldn't warn on using
a mutex that was previously destroyed, when in fact the destroy call has failed.
Patch by Malhar Thakkar!
Differential revision: https://reviews.llvm.org/D32449
llvm-svn: 304159
It was written as "Memory Error" in most places and as "Memory error" in a few
other places, however it is the latter that is more consistent with
other categories (such as "Logic error").
rdar://problem/31718115
Differential Revision: https://reviews.llvm.org/D32702
llvm-svn: 302016
Array-to-pointer cast now works correctly when the pointer to the array
is concrete, eg. null, which allows further symbolic calculations involving
such values.
Inlined defensive checks are now detected correctly when the resulting null
symbol is being array-subscripted before dereference.
Differential Revision: https://reviews.llvm.org/D32291
llvm-svn: 301251
Null dereferences are suppressed if the lvalue was constrained to 0 for the
first time inside a sub-function that was inlined during analysis, because
such constraint is a valid defensive check that does not, by itself,
indicate that null pointer case is anyhow special for the caller.
If further operations on the lvalue are performed, the symbolic lvalue is
collapsed to concrete null pointer, and we need to track where does the null
pointer come from.
Improve such tracking for lvalue operations involving operator &.
rdar://problem/27876009
Differential Revision: https://reviews.llvm.org/D31982
llvm-svn: 301224
This diff replaces getTypeSize(CondE->getType()))
with getIntWidth(CondE->getType())) in ExprEngine::processSwitch.
These calls are not equivalent for bool, see ASTContext.cpp
Add a test case.
Test plan:
make check-clang-analysis
make check-clang
Differential revision: https://reviews.llvm.org/D32328
llvm-svn: 300936
SValBuilder tries to constant-fold symbols in the left-hand side of the symbolic
expression whenever it fails to evaluate the expression directly. However, it
only constant-folds them when they are atomic expressions, not when they are
complicated expressions themselves. This patch adds recursive constant-folding
to the left-hand side subexpression (there's a lack of symmetry because we're
trying to have symbols on the left and constants on the right). As an example,
we'd now be able to handle operations similar to "$x + 1 < $y", when $x is
constrained to a constant.
rdar://problem/31354676
Differential Revision: https://reviews.llvm.org/D31886
llvm-svn: 300178
This diff adds a defensive check in getExtraInvalidatedValues
for the case when there are no regions for the ivar associated with
a property. Corresponding test case added.
Test plan:
make check-clang
make check-clang-analysis
llvm-svn: 300114
Move the test format into a standalone .py file and add it to the site
module search path. This allows us to run the test on Windows, and it
makes it compatible with the multiprocessing.Pool lit test execution
strategy.
I think this test was only passing everywhere else because
multiprocessing uses 'fork' to spawn workers, so the test format never
needs to be pickled.
llvm-svn: 299577
Summary:
The alpha.core.Conversion was too strict about compound assignments and could warn even though there is no problem.
Differential Revision: https://reviews.llvm.org/D25596
llvm-svn: 299523
If the value is known, but we cannot increment it, conjure a symbol to
represent the result of the operation based on the operator expression,
not on the sub-expression.
In particular, no longer crash on comparing a result of a LocAsInteger increment
to a constant integer.
rdar://problem/31067356
Differential Revision: https://reviews.llvm.org/D31289
llvm-svn: 298927
Adjustments should be considered properly; we should copy the unadjusted object
over the whole temporary base region. If the unadjusted object is no longer
available in the Environment, invalidate the temporary base region, and then
copy the adjusted object into the adjusted sub-region of the temporary region.
This fixes a regression introduced by r288263, that caused various
false positives, due to copying only adjusted object into the adjusted region;
the rest of the base region therefore remained undefined.
Before r288263, the adjusted value was copied over the unadjusted region,
which is incorrect, but accidentally worked better due to how region store
disregards compound value bindings to non-base regions.
An additional test machinery is introduced to make sure that despite making
two binds, we only notify checkers once for both of them, without exposing
the partially copied objects.
This fix is a hack over a hack. The proper fix would be to model C++ temporaries
in the CFG, and after that dealing with adjustments would no longer be
necessary, and the values we need would no longer disappear from the
Environment.
rdar://problem/30658168
Differential Revision: https://reviews.llvm.org/D30534
llvm-svn: 298924
The checker currently warns on copying, moving, or calling methods on an object
that was recently std::move'd from. It understands a set of "state reset"
methods that bring a moved-from object back to a well-specified state.
Patch by Peter Szecsi!
Differential Revision: https://reviews.llvm.org/D24246
llvm-svn: 298698
It looks like on some host-triples the result of a valist related expr can be
a LazyCompoundVal. Handle that case in the check.
Patch by Abramo Bagnara!
llvm-svn: 297619
We have several reports of false positives coming from libc++. For example,
there are reports of false positives in std::regex, std::wcout, and also
a bunch of issues are reported in https://reviews.llvm.org/D30593. In many
cases, the analyzer trips over the complex libc++ code invariants. Let's turn
off the reports coming from these headers until we can re-evalate the support.
We can turn this back on once we individually suppress all known false
positives and perform deeper evaluation on large codebases that use libc++.
We'd also need to commit to doing these evaluations regularly as libc++
headers change.
Differential Revision: https://reviews.llvm.org/D30798
llvm-svn: 297429
George Karpenkov