[analyzer] Remove NotifyAssumeClients

Depends on D126560.

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

[analyzer] Implement assumeInclusiveRange in terms of assumeInclusiveRangeDual

Depends on D124758. This is the very same thing we have done for
assumeDual, but this time we do it for assumeInclusive

[analyzer] Implement assumeInclusiveRange in terms of assumeInclusiveRangeDual

Depends on D124758. This is the very same thing we have done for
assumeDual, but this time we do it for assumeInclusiveRange. This patch
is basically a no-brainer copy of that previous patch.

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

show more ...

[analyzer] Implement assume in terms of assumeDual

Summary:
By evaluating both children states, now we are capable of discovering
infeasible parent states. In this patch, `assume` is implemented in

[analyzer] Implement assume in terms of assumeDual

Summary:
By evaluating both children states, now we are capable of discovering
infeasible parent states. In this patch, `assume` is implemented in the terms
of `assumeDuali`. This might be suboptimal (e.g. where there are adjacent
assume(true) and assume(false) calls, next patches addresses that). This patch
fixes a real CRASH.
Fixes https://github.com/llvm/llvm-project/issues/54272

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

show more ...

[analyzer] Simplify function SVal::getAsSymbolicExpression and similar ones

Summary: Simplify functions SVal::getAsSymbolicExpression SVal::getAsSymExpr and SVal::getAsSymbol. After revision I concl

[analyzer] Simplify function SVal::getAsSymbolicExpression and similar ones

Summary: Simplify functions SVal::getAsSymbolicExpression SVal::getAsSymExpr and SVal::getAsSymbol. After revision I concluded that `getAsSymbolicExpression` and `getAsSymExpr` repeat functionality of `getAsSymbol`, thus them can be removed.

Fix: Remove functions SVal::getAsSymbolicExpression and SVal::getAsSymExpr.

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

show more ...

[Analyzer][NFC] Remove the SubEngine interface

The `SubEngine` interface is an interface with only one implementation
`EpxrEngine`. Adding other implementations are difficult and very
unlikely in th

[Analyzer][NFC] Remove the SubEngine interface

The `SubEngine` interface is an interface with only one implementation
`EpxrEngine`. Adding other implementations are difficult and very
unlikely in the near future. Currently, if anything from `ExprEngine` is
to be exposed to other classes it is moved to `SubEngine` which
restricts the alternative implementations. The virtual methods are have
a slight perofrmance impact. Furthermore, instead of the `LLVM`-style
inheritance a native inheritance is used here, which renders `LLVM`
functions like e.g. `cast<T>()` unusable here. This patch removes this
interface and allows usage of `ExprEngine` directly.

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

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[analyzer] Refactor and simplify SimpleConstraintManager

Summary: SimpleConstraintManager is difficult to use, and makes assumptions about capabilities of the constraint manager. This patch refactor

[analyzer] Refactor and simplify SimpleConstraintManager

Summary: SimpleConstraintManager is difficult to use, and makes assumptions about capabilities of the constraint manager. This patch refactors out those portions into a new RangedConstraintManager, and also fixes some issues with camel case, formatting, and confusing naming.

Reviewers: zaks.anna, dcoughlin

Subscribers: mgorny, xazax.hun, NoQ, rgov, cfe-commits

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

llvm-svn: 296242

show more ...

Fix for PR15623 (corrected r290413 reverted at 290415). The patch eliminates unwanted ProgramState checker data propagation from an operand of the logical operation to operation result.
The patch als

Fix for PR15623 (corrected r290413 reverted at 290415). The patch eliminates unwanted ProgramState checker data propagation from an operand of the logical operation to operation result.
The patch also simplifies an assume of a constraint of the form: "(exp comparison_op expr) != 0" to true into an assume of "exp comparison_op expr" to true. (And similarly, an assume of the form "(exp comparison_op expr) == 0" to true as an assume of exp comparison_op expr to false.) which improves precision overall.
https://reviews.llvm.org/D22862

llvm-svn: 290505

show more ...

Revert changes made by r290413 until regression is fixed.

llvm-svn: 290415

Fix for PR15623. The patch eliminates unwanted ProgramState checker data propagation from an operand of the logical operation to operation result.
The patch also simplifies an assume of a constraint

Fix for PR15623. The patch eliminates unwanted ProgramState checker data propagation from an operand of the logical operation to operation result.
The patch also simplifies an assume of a constraint of the form: "(exp comparison_op expr) != 0" to true into an assume of "exp comparison_op expr" to true. (And similarly, an assume of the form "(exp comparison_op expr) == 0" to true as an assume of exp comparison_op expr to false.) which improves precision overall.
https://reviews.llvm.org/D22862

llvm-svn: 290413

show more ...

[analyzer] Add a new SVal to support pointer-to-member operations.

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

[analyzer] Add a new SVal to support pointer-to-member operations.

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

llvm-svn: 289873

show more ...

[analyzer] Run clang-format and fix style

Summary: Split out formatting and style changes from D26061

Reviewers: zaks.anna, dcoughlin

Subscribers: cfe-commits

Differential Revision: https://revie

[analyzer] Run clang-format and fix style

Summary: Split out formatting and style changes from D26061

Reviewers: zaks.anna, dcoughlin

Subscribers: cfe-commits

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

llvm-svn: 289511

show more ...

[analyzer] Rename assumeWithinInclusiveRange*()

Summary: The name is slightly confusing, since the constraint is not necessarily within the range unless `Assumption` is true. Split out renaming for

[analyzer] Rename assumeWithinInclusiveRange*()

Summary: The name is slightly confusing, since the constraint is not necessarily within the range unless `Assumption` is true. Split out renaming for ConstraintManager.h from D26061

Reviewers: zaks.anna, dcoughlin

Subscribers: cfe-commits

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

llvm-svn: 286927

show more ...

Roll-back r250822.

Summary: It breaks the build for the ASTMatchers

Subscribers: klimek, cfe-commits

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

llvm-svn: 250827

Apply modernize-use-default to clang.

Summary: Replace empty bodies of default constructors and destructors with '= default'.

Reviewers: bkramer, klimek

Subscribers: klimek, alexfh, cfe-commits

D

Apply modernize-use-default to clang.

Summary: Replace empty bodies of default constructors and destructors with '= default'.

Reviewers: bkramer, klimek

Subscribers: klimek, alexfh, cfe-commits

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

llvm-svn: 250822

show more ...

[analyzer] Create one state for a range switch case instead of multiple.

This fixes PR16833, in which the analyzer was using large amounts of memory
for switch statements with large case ranges.

rd

[analyzer] Create one state for a range switch case instead of multiple.

This fixes PR16833, in which the analyzer was using large amounts of memory
for switch statements with large case ranges.

rdar://problem/14685772

A patch by Aleksei Sidorin!

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

llvm-svn: 248318

show more ...

[C++11] Use 'nullptr'. StaticAnalyzer edition.

llvm-svn: 209642

[analyzer] Add support for testing the presence of weak functions.

When casting the address of a FunctionTextRegion to bool, or when adding
constraints to such an address, use a stand-in symbol to r

[analyzer] Add support for testing the presence of weak functions.

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 <[email protected]>!

llvm-svn: 189492

show more ...

[analyzer] Ensure BugReporterTracking works on regions with pointer arithmetic

Introduce a new helper function, which computes the first symbolic region in
the base region chain. The corresponding s

[analyzer] Ensure BugReporterTracking works on regions with pointer arithmetic

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.

llvm-svn: 179916

show more ...

[analyzer] Replace isIntegerType() with isIntegerOrEnumerationType().

Previously, the analyzer used isIntegerType() everywhere, which uses the C
definition of "integer". The C++ predicate with the s

[analyzer] Replace isIntegerType() with isIntegerOrEnumerationType().

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>

llvm-svn: 179081

show more ...

[analyzer] Teach ConstraintManager to ignore NonLoc <> NonLoc comparisons.

These aren't generated by default, but they are needed when either side of
the comparison is tainted.

Should fix our inter

[analyzer] Teach ConstraintManager to ignore NonLoc <> NonLoc comparisons.

These aren't generated by default, but they are needed when either side of
the comparison is tainted.

Should fix our internal buildbot.

llvm-svn: 177846

show more ...

[analyzer] Teach constraint managers about unsigned comparisons.

In C, comparisons between signed and unsigned numbers are always done in
unsigned-space. Thus, we should know that "i >= 0U" is alway

[analyzer] Teach constraint managers about unsigned comparisons.

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)

llvm-svn: 177806

show more ...

[analyzer] Also transform "a < b" to "(b - a) > 0" in the constraint manager.

We can support the full range of comparison operations between two locations
by canonicalizing them as subtraction, as i

[analyzer] Also transform "a < b" to "(b - a) > 0" in the constraint manager.

We can support the full range of comparison operations between two locations
by canonicalizing them as subtraction, as in the previous commit.

This won't work (well) if either location includes an offset, or (again)
if the comparisons are not consistent about which region comes first.

<rdar://problem/13239003>

llvm-svn: 177803

show more ...

Add reverseComparisonOp and negateComparisonOp to BinaryOperator.

...and adopt them in the analyzer.

llvm-svn: 177802

[analyzer] Translate "a != b" to "(b - a) != 0" in the constraint manager.

Canonicalizing these two forms allows us to better model containers like
std::vector, which use "m_start != m_finish" to im

[analyzer] Translate "a != b" to "(b - a) != 0" in the constraint manager.

Canonicalizing these two forms allows us to better model containers like
std::vector, which use "m_start != m_finish" to implement empty() but
"m_finish - m_start" to implement size(). The analyzer should have a
consistent interpretation of these two symbolic expressions, even though
it's not properly reasoning about either one yet.

The other unfortunate thing is that while the size() expression will only
ever be written "m_finish - m_start", the comparison may be written
"m_finish == m_start" or "m_start == m_finish". Right now the analyzer does
not attempt to canonicalize those two expressions, since it doesn't know
which length expression to pick. Doing this correctly will probably require
implementing unary minus as a new SymExpr kind (<rdar://problem/12351075>).

For now, the analyzer inverts the order of arguments in the comparison to
build the subtraction, on the assumption that "begin() != end()" is
written more often than "end() != begin()". This is purely speculation.

<rdar://problem/13239003>

llvm-svn: 177801

show more ...