| Age | Commit message (Collapse) | Author |
|---|
|
The one user has been changed to use getLValue on the compound literal
expression and then use the normal bindLoc to assign a value. No need
to special case this in the StoreManager.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181214 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
...and don't consider '0' to be a null pointer constant if it's the
initializer for a float!
Apparently null pointer constant evaluation looks through both
MaterializeTemporaryExpr and ImplicitCastExpr, so we have to be more
careful about types in the callers. For RegionStore this just means giving
up a little more; for ExprEngine this means handling the
MaterializeTemporaryExpr case explicitly.
Follow-up to r180894.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180944 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Previously, this was scattered across Environment (literal expressions),
ExprEngine (default arguments), and RegionStore (global constants). The
former special-cased several kinds of simple constant expressions, while
the latter two deferred to the AST's constant evaluator.
Now, these are all unified as SValBuilder::getConstantVal(). To keep
Environment fast, the special cases for simple constant expressions have
been left in, but the main benefits are that (a) unusual constants like
ObjCStringLiterals now work as default arguments and global constant
initializers, and (b) we're not duplicating code between ExprEngine and
RegionStore.
This actually caught a bug in our test suite, which is awesome: we stop
tracking allocated memory if it's passed as an argument along with some
kind of callback, but not if the callback is 0. We were testing this in
a case where the callback parameter had a default value, but that value
was 0. After this change, the analyzer now (correctly) flags that as a
leak!
<rdar://problem/13773117>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180894 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
PathDiagnosticLocation::createEndOfPath for greater code reuse
The 2 functions were computing the same location using different logic (each one had edge case bugs that the other
one did not). Refactor them to rely on the same logic.
The location of the warning reported in text/command line output format will now match that of the plist file.
There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the
operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and
looks better in most cases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180165 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Introduce a new helper function, which computes the first symbolic region in
the base region chain. The corresponding symbol has been used for assuming that
a pointer is null. Now, it will also be used for checking if it is null.
This ensures that we are tracking a null pointer correctly in the BugReporter.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179916 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Jordan (r179572)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179915 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
APIs that access the configuration table without clients reasoning
about the string table. The string table is an implementation
detail.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179625 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179573 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Mostly refactoring + handle the nested fields by printing the innermost field only.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179572 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179395 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179269 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Previously, the analyzer used isIntegerType() everywhere, which uses the C
definition of "integer". The C++ predicate with the same behavior is
isIntegerOrUnscopedEnumerationType().
However, the analyzer is /really/ using this to ask if it's some sort of
"integrally representable" type, i.e. it should include C++11 scoped
enumerations as well. hasIntegerRepresentation() sounds like the right
predicate, but that includes vectors, which the analyzer represents by its
elements.
This commit audits all uses of isIntegerType() and replaces them with the
general isIntegerOrEnumerationType(), except in some specific cases where
it makes sense to exclude scoped enumerations, or any enumerations. These
cases now use isIntegerOrUnscopedEnumerationType() and getAs<BuiltinType>()
plus BuiltinType::isInteger().
isIntegerType() is hereby banned in the analyzer - lib/StaticAnalysis and
include/clang/StaticAnalysis. :-)
Fixes real assertion failures. PR15703 / <rdar://problem/12350701>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179081 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to be invalidated
Refactor invalidateRegions to take SVals instead of Regions as input and teach RegionStore
about processing LazyCompoundVal as a top-level “escaping” value.
This addresses several false positives that get triggered by the NewDelete checker, but the
underlying issue is reproducible with other checkers as well (for example, MallocChecker).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178518 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Certain properties of a function can determine ahead of time whether or not
the function is inlineable, such as its kind, its signature, or its
location. We can cache this value in the FunctionSummaries map to avoid
rechecking these static properties for every call.
Note that the analyzer may still decide not to inline a specific call to
a function because of the particular dynamic properties of the call along
the current path.
No intended functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178515 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The summaries lasted for the lifetime of the map anyway; no reason to
include an extra allocation.
Also, use SmallBitVector instead of BitVector to track the visited basic
blocks -- most functions will have less than 64 basic blocks -- and
use bitfields for the other fields to reduce the size of the structure.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178514 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178318 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
“newed” pointers to escape
Add a new callback that notifies checkers when a const pointer escapes. Currently, this only works
for const pointers passed as a top level parameter into a function. We need to differentiate the const
pointers escape from regular escape since the content pointed by const pointer will not change;
if it’s a file handle, a file cannot be closed; but delete is allowed on const pointers.
This should suppress several false positives reported by the NewDelete checker on llvm codebase.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178310 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178247 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Now that the basic implementation in llvm has been fixed, simplify the
specializations in clang.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178173 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
ObjC methods as top level.
This allows us to better reason about(inline) small wrapper functions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178063 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
In C, comparisons between signed and unsigned numbers are always done in
unsigned-space. Thus, we should know that "i >= 0U" is always true, even
if 'i' is signed. Similarly, "u >= 0" is also always true, even though '0'
is signed.
Part of <rdar://problem/13239003> (false positives related to std::vector)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177806 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The algorithm used here was ridiculously slow when a potential back-edge
pointed to a node that already had a lot of successors. The previous commit
makes this feature unnecessary anyway.
This reverts r177468 / f4cf6b10f863b9bc716a09b2b2a8c497dcc6aa9b.
Conflicts:
lib/StaticAnalyzer/Core/BugReporter.cpp
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177765 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
In this case, the value of 'x' may be changed after the call to indirectAccess:
struct Wrapper {
int *ptr;
};
void indirectAccess(const Wrapper &w);
void test() {
int x = 42;
Wrapper w = { x };
clang_analyzer_eval(x == 42); // TRUE
indirectAccess(w);
clang_analyzer_eval(x == 42); // UNKNOWN
}
This is important for modelling return-by-value objects in C++, to show
that the contents of the struct are escaping in the return copy-constructor.
<rdar://problem/13239826>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177570 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Having a trimmed graph with no cycles (a DAG) is much more convenient for
trying to find shortest paths, which is exactly what BugReporter needs to do.
Part of the performance work for <rdar://problem/13433687>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177468 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
r175234 allowed the analyzer to model trivial copy/move constructors as
an aggregate bind. This commit extends that to trivial assignment
operators as well. Like the last commit, one of the motivating factors here
is not warning when the right-hand object is partially-initialized, which
can have legitimate uses.
<rdar://problem/13405162>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177220 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
...in favor of this typedef:
typedef llvm::DenseMap<const ExplodedNode *, const ExplodedNode *>
InterExplodedGraphMap;
Use this everywhere the previous class and typedef were used.
Took the opportunity to ArrayRef-ize ExplodedGraph::trim while I'm at it.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177215 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176600 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176469 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Inlining brought a few "null pointer use" false positives, which occur because
the callee defensively checks if a pointer is NULL, whereas the caller knows
that the pointer cannot be NULL in the context of the given call.
This is a first attempt to silence these warnings by tracking the symbolic value
along the execution path in the BugReporter. The new visitor finds the node
in which the symbol was first constrained to NULL. If the node belongs to
a function on the active stack, the warning is reported, otherwise, it is
suppressed.
There are several areas for follow up work, for example:
- How do we differentiate the cases where the first check is followed by
another one, which does happen on the active stack?
Also, this only silences a fraction of null pointer use warnings. For example, it
does not do anything for the cases where NULL was assigned inside a callee.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176402 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Pure optimization, no functionality change. Probably does not make much
of a difference, but it's free.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176229 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176043 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
ExplodedNode pruning.
r175988 modified the ExplodedGraph trimming algorithm to retain all
nodes for "lvalue" expressions. This patch refines that notion to
only "interesting" expressions that would be used for diagnostics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176010 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
fields.
This required more changes than I originally expected:
- ObjCIvarRegion implements "canPrintPretty" et al
- DereferenceChecker indicates the null pointer source is an ivar
- bugreporter::trackNullOrUndefValue() uses an alternate algorithm
to compute the location region to track by scouring the ExplodedGraph.
This allows us to get the actual MemRegion for variables, ivars,
fields, etc. We only hand construct a VarRegion for C++ references.
- ExplodedGraph no longer drops nodes for expressions that are marked
'lvalue'. This is to facilitate the logic in the previous bullet.
This may lead to a slight increase in size in the ExplodedGraph,
which I have not measured, but it is likely not to be a big deal.
I have validated each of the changed plist output.
Fixes <rdar://problem/12114812>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175988 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This provides a few sundry cleanups, and allows us to provide
a compile-time check for a case that was a runtime assertion.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175987 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Previously, we had the decisions about inlining spread out
over multiple functions.
In addition to the refactor, this commit ensures
that we will always inline BodyFarm functions as long as the Decl
is available. This fixes false positives due to those functions
not being inlined when no or minimal inlining is enabled such (as
shallow mode).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175857 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is a follow-up to r175830, which made sure a temporary object region
created for, say, a struct rvalue matched up with the initial bindings
being stored into it. This does the same for the case in which the AST
actually tells us that we need to create a temporary via a
MaterializeObjectExpr. I've unified the two code paths and moved a static
helper function onto ExprEngine.
This also caused a bit of test churn, causing us to go back to describing
temporary regions without a 'const' qualifier. This seems acceptable; it's
our behavior from a few months ago.
<rdar://problem/13265460> (part 2)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175854 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
See r175462 for another example/more details.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175812 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This allows MemRegion and MemRegionManager to avoid asking over and over
again whether an class is a virtual base or a non-virtual base.
Minor optimization/cleanup; no functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175716 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175705 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Also document TypeLoc's operations similarly, since it's a good idea.
Post-commit CR feedback from Anna Zaks regarding r175594.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175694 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Post-commit CR feedback from Jordan Rose regarding r175594.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175679 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Post-commit CR feedback from Jordan Rose regarding r175594.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175676 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
See r175462 for another example/more details.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175594 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Also removes some redundant DNI comments on function declarations already
using the macro.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175465 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
...after a host of optimizations related to the use of LazyCompoundVals
(our implementation of aggregate binds).
Originally applied in r173951.
Reverted in r174069 because it was causing hangs.
Re-applied in r174212.
Reverted in r174265 because it was /still/ causing hangs.
If this needs to be reverted again it will be punted to far in the future.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175234 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174782 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is a more natural order of evaluation, and it is very important
for visualization in the static analyzer. Within Xcode, the arrows
will not jump from right to left, which looks very visually jarring.
It also provides a more natural location for dataflow-based diagnostics.
Along the way, we found a case in the analyzer diagnostics where we
needed to indicate that a variable was "captured" by a block.
-fsyntax-only timings on sqlite3.c show no visible performance change,
although this is just one test case.
Fixes <rdar://problem/13016513>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174447 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
...again. The problem has not been fixed and our internal buildbot is still
getting hangs.
This reverts r174212, originally applied in r173951, then reverted in r174069.
Will not re-apply until the entire project analyzes successfully on my
local machine.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174265 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
With the optimization in the previous commit, this should be safe again.
Originally applied in r173951, then reverted in r174069.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174212 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This allows us to keep from chaining LazyCompoundVals in cases like this:
CGRect r = CGRectMake(0, 0, 640, 480);
CGRect r2 = r;
CGRect r3 = r2;
Previously we only made this optimization if the struct did not begin with
an aggregate member, to make sure that we weren't picking up an LCV for
the first field of the struct. But since LazyCompoundVals are typed, we can
make that inference directly by comparing types.
This is a pure optimization; the test changes are to guard against possible
future regressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174211 91177308-0d34-0410-b5e6-96231b3b80d8
|
