Assertion `Loc::isLocType(SSE->getLHS()->getType())' failed in Analysis/PR3991.m

This reverts commit e469ff27.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@307853 91177308-0d34-0410-b5e6-96231b3b80d8

Summary: Generate more IntSymExpr constraints, perform SVal simplification for IntSymExpr and SymbolCast constraints, and create fully symbolic SymExprs

Reviewers: zaks.anna, dcoughlin, NoQ, xazax.hun

Subscribers: mgorny, cfe-commits

Differential Revision: https://reviews.llvm.org/D28953

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@307833 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@304644 91177308-0d34-0410-b5e6-96231b3b80d8

Sema treats pointers to static member functions as having function pointer
type, so treat treat them as function pointer values in the analyzer as well.
This prevents an assertion failure in SValBuilder::evalBinOp caused by code
that expects function pointers to be Locs (in contrast, PointerToMember values
are nonlocs).

Differential Revision: https://reviews.llvm.org/D28033

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291581 91177308-0d34-0410-b5e6-96231b3b80d8

Add a new type of NonLoc SVal for C++ pointer-to-member operations. This SVal
supports both pointers to member functions and pointers to member data.

A patch by Kirill Romanenkov!

Differential Revision: https://reviews.llvm.org/D25475

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289873 91177308-0d34-0410-b5e6-96231b3b80d8

copy constructors of classes with array members, instead using
ArrayInitLoopExpr to represent the initialization loop.

This exposed a bug in the static analyzer where it was unable to differentiate
between zero-initialized and unknown array values, which has also been fixed
here.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289618 91177308-0d34-0410-b5e6-96231b3b80d8

Like SymbolConjured, SymbolMetadata also needs to be uniquely
identified by the moment of its birth.

Such moments are coded by the (Statement, LocationContext, Block count) triples.
Each such triple represents the moment of analyzing a statement with a certain
call backtrace, with corresponding CFG block having been entered a given amount
of times during analysis of the current code body.

The LocationContext information was accidentally omitted for SymbolMetadata,
which leads to reincarnation of SymbolMetadata upon re-entering a code body
with a different backtrace; the new symbol is incorrectly unified with
the old symbol, which leads to unsound assumptions.

Patch by Alexey Sidorin!

Differential Revision: https://reviews.llvm.org/D21978


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@278937 91177308-0d34-0410-b5e6-96231b3b80d8

Instead, return UnknownValue if either operand is a nonloc::LazyCompoundVal. This is a
spot fix for PR 24951.

rdar://problem/23682244

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260066 91177308-0d34-0410-b5e6-96231b3b80d8

Make sure that we do not add SymbolCast at the very boundary of
the range in which the cast would not certainly happen.

Differential Revision: http://reviews.llvm.org/D16178


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@258039 91177308-0d34-0410-b5e6-96231b3b80d8

The purpose of these changes is to simplify introduction of definition files
for the three hierarchies.

1. For every sub-class C of these classes, its kind in the relevant enumeration
is changed to "CKind" (or C##Kind in preprocessor-ish terms), eg:

  MemRegionKind   -> MemRegionValKind
  RegionValueKind -> SymbolRegionValueKind
  CastSymbolKind  -> SymbolCastKind
  SymIntKind      -> SymIntExprKind

2. MemSpaceRegion used to be inconsistently used as both an abstract base and
a particular region. This region class is now an abstract base and no longer
occupies GenericMemSpaceRegionKind. Instead, a new class, CodeSpaceRegion,
is introduced for handling the unique use case for MemSpaceRegion as
"the generic memory space" (when it represents a memory space that holds all
executable code).

3. BEG_ prefixes in memory region kind ranges are renamed to BEGIN_ for
consisitency with symbol kind ranges.

4. FunctionTextRegion and BlockTextRegion are renamed to FunctionCodeRegion and
BlockCodeRegion, respectively. The term 'code' is less jargony than 'text' and
we already refer to BlockTextRegion as a 'code region' in BlockDataRegion.

Differential Revision: http://reviews.llvm.org/D16062


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@257598 91177308-0d34-0410-b5e6-96231b3b80d8

The current workaround for truncations not being modelled is that the evaluation of integer to integer casts are simply bypassed and so the original symbol is used as the new casted symbol (cf SimpleSValBuilder::evalCastFromNonLoc).
This lead to the issue described in PR25078, as the RangeConstraintManager associates ranges with symbols.

The new evalIntegralCast method added by this patch wont bypass the cast if it finds the range of the symbol to be greater than the maximum value of the target type.

The fix to RangeSet::pin mentioned in the initial review will be committed separately.

Differential Revision: http://reviews.llvm.org/D12901

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@257464 91177308-0d34-0410-b5e6-96231b3b80d8

Differential Revision: http://reviews.llvm.org/D15007


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@254718 91177308-0d34-0410-b5e6-96231b3b80d8

Conversions between unrelated pointer types (e.g. char * and void *) involve
bitcasts which were not properly modeled in case of static initializers. The
patch fixes this problem.

The problem was originally spotted by Artem Dergachev. Patched by Yuri Gribov!

Differential Revision: http://reviews.llvm.org/D14652

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253532 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
`TypeTraitExpr`s are not supported by the ExprEngine today. Analyzer
creates a sink, and aborts the block. Therefore, certain bugs that
involve type traits intrinsics cannot be detected (see PR24710).

This patch creates boolean `SVal`s for `TypeTraitExpr`s, which are
evaluated by the compiler.

Test within the patch is a summary of PR24710.

Reviewers: zaks.anna, dcoughlin, krememek

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D12482

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248314 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246978 91177308-0d34-0410-b5e6-96231b3b80d8

We have assertions for this, but a few edge cases had snuck through where
we were still unconditionally using 'int'.

<rdar://problem/15703011>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@197733 91177308-0d34-0410-b5e6-96231b3b80d8

This patch tries to avoid unrelated changes other than fixing a few
hyphen-related ambiguities in nearby lines.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@196466 91177308-0d34-0410-b5e6-96231b3b80d8

[analyzer] Fix an infinite recursion in region invalidation by adding block count to the BlockDataRegion.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@195174 91177308-0d34-0410-b5e6-96231b3b80d8

We now have symbols with floating-point type to make sure that
(double)x == (double)x comes out true, but we still can't do much with
these. For now, don't even bother trying to create a floating-point zero
value; just give up on conversion to bool.

PR14634, C++ edition.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190953 91177308-0d34-0410-b5e6-96231b3b80d8

When casting the address of a FunctionTextRegion to bool, or when adding
constraints to such an address, use a stand-in symbol to represent the
presence or absence of the function if the function is weakly linked.
This is groundwork for possible simple availability testing checks, and
can already catch mistakes involving inverted null checks for
weakly-linked functions.

Currently, the implementation reuses the "extent" symbols, originally created
for tracking the size of a malloc region. Since FunctionTextRegions cannot
be dereferenced, the extent symbol will never be used for anything else.
Still, this probably deserves a refactoring in the future.

This patch does not attempt to support testing the presence of weak
/variables/ (global variables), which would likely require much more of
a change and a generalization of "region structure metadata", like the
current "extents", vs. "region contents metadata", like CStringChecker's
"string length".

Patch by Richard <tarka.t.otter@googlemail.com>!

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189492 91177308-0d34-0410-b5e6-96231b3b80d8

PR16690

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@187132 91177308-0d34-0410-b5e6-96231b3b80d8

Previously, SValBuilder knew how to evaluate StringLiterals, but couldn't
handle an array-to-pointer decay for constant values. Additionally,
RegionStore was being too strict about loading from an array, refusing to
return a 'char' value from a 'const char' array. Both of these have been
fixed.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186520 91177308-0d34-0410-b5e6-96231b3b80d8

This gives slightly better precision, specifically, in cases where a non-typed region represents the array
or when the type is a non-array type, which can happen when an array is a result of a reinterpret_cast.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182810 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

This doesn't appear to be the cause of the slowdown. I'll have to try a
manual bisect to see if there's really anything there, or if it's just
the bot itself taking on additional load. Meanwhile, this change helps
with correctness.

This changes an assertion and adds a test case, then re-applies r180638,
which was reverted in r180714.

<rdar://problem/13296133> and PR15863

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180864 91177308-0d34-0410-b5e6-96231b3b80d8

This seems to be causing quite a slowdown on our internal analyzer bot,
and I'm not sure why. Needs further investigation.

This reverts r180638 / 9e161ea981f22ae017b6af09d660bfc3ddf16a09.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180714 91177308-0d34-0410-b5e6-96231b3b80d8

Casts to bool (and _Bool) are equivalent to checks against zero,
not truncations to 1 bit or 8 bits.

This improved reasoning does cause a change in the behavior of the alpha
BoolAssignment checker. Previously, this checker complained about statements
like "bool x = y" if 'y' was known not to be 0 or 1. Now it does not, since
that conversion is well-defined. It's hard to say what the "best" behavior
here is: this conversion is safe, but might be better written as an explicit
comparison against zero.

More usefully, besides improving our model of booleans, this fixes spurious
warnings when returning the address of a local variable cast to bool.

<rdar://problem/13296133>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180638 91177308-0d34-0410-b5e6-96231b3b80d8

When computing the value of ?: expression, we rely on the last expression in
the previous basic block to be the resulting value of the expression. This is
not the case for binary "?:" operator (GNU extension) in C++. As the last
basic block has the expression for the condition subexpression, which is an
R-value, whereas the true subexpression is the L-value.

Note the operator evaluation just happens to work in C since the true
subexpression is an R-value (like the condition subexpression). CFG is the
same in C and C++ case, but the AST nodes are different, which the LValue to
Rvalue conversion happening after the BinaryConditionalOperator evaluation.

Changed the logic to only use the last expression from the predecessor only
if it matches either true or false subexpression. Note, the logic needed
fortification anyway: L and R were passed but not even used by the function.

Also, change the conjureSymbolVal to correctly compute the type, when the
expression is an LG-value.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179574 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

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

See r175462 for another example/more details.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175594 91177308-0d34-0410-b5e6-96231b3b80d8

(void*)p.

Addresses the false positives similar to the test case.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174436 91177308-0d34-0410-b5e6-96231b3b80d8

uncovered.

This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.

I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169237 91177308-0d34-0410-b5e6-96231b3b80d8

No need to have the "get", the word "conjure" is a verb too!
Getting a conjured symbol is the same as conjuring one up.

This shortening is largely cosmetic, but just this simple changed
cleaned up a handful of lines, making them less verbose.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162348 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159047 91177308-0d34-0410-b5e6-96231b3b80d8

Add a concept of symbolic memory region belonging to heap memory space.
When comparing symbolic regions allocated on the heap, assume that they
do not alias. 

Use symbolic heap region to suppress a common false positive pattern in
the malloc checker, in code that relies on malloc not returning the
memory aliased to other malloc allocations, stack.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158136 91177308-0d34-0410-b5e6-96231b3b80d8

pointer.

Fixes one of the crashes reported in PR12874.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@157401 91177308-0d34-0410-b5e6-96231b3b80d8

The resulting type info is stored in the SymSymExpr, so no reason not to
support construction of expression with different subexpression types.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156051 91177308-0d34-0410-b5e6-96231b3b80d8

(Currently, this is only relevant for tainted data.)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156050 91177308-0d34-0410-b5e6-96231b3b80d8