[analysis][NFC] clean unittest log (#123758)

1. clean llvm::errs ouput
2. add -Wno-everything option to suppress clang warning during test

[clang][CFG] Change child order in Reverse Post Order (RPO) iteration. (#80030)

The CFG orders the blocks of loop bodies before those of loop successors
(both numerically, and in the successor orde

[clang][CFG] Change child order in Reverse Post Order (RPO) iteration. (#80030)

The CFG orders the blocks of loop bodies before those of loop successors
(both numerically, and in the successor order of the loop condition
block). So, RPO necessarily reverses that order, placing the loop
successor *before* the loop body. For many analyses, particularly those
that converge to a fixpoint, this results in potentially significant
extra work, because loop successors will necessarily need to be
reconsidered once the algorithm has reached a fixpoint on the loop body.

This definition of CFG graph traits reverses the order of children, so
that loop bodies will come first in an RPO. Then, the algorithm can
fully evaluate the loop and only then consider successor blocks.

show more ...

[clang][dataflow] Refactor `DataflowWorklist` types and add a WTO version.

Removes dependency of the DataflowWorklistBase type on the PostOrderCFGView. The
base had no particular connection to this

[clang][dataflow] Refactor `DataflowWorklist` types and add a WTO version.

Removes dependency of the DataflowWorklistBase type on the PostOrderCFGView. The
base had no particular connection to this order -- looks like it was included as
a convenience to the two derived classes rather than because it belonged there
conceptually. Removing it cleans up the base class a bit and makes it suitable
to extension with the new WTODataflowWorklist class.

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

show more ...

[CFG] Fix crash on CFG building when deriving from a template.

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

[DataFlow] Factor two worklist implementations out

Right now every dataflow algorithm uses its own worklist implementation.
This is a first step to reduce this duplication. Some upcoming
algorithms

[DataFlow] Factor two worklist implementations out

Right now every dataflow algorithm uses its own worklist implementation.
This is a first step to reduce this duplication. Some upcoming
algorithms such as the lifetime analysis is going to use the factored
out implementations.

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

show more ...

[CFG] Fix an assertion failure with static initializers

The CFGBlock::getLastCondition was not prepared for static initializer
branches.

This patch also revamps CFG unit tests. Earlier the lifetime

[CFG] Fix an assertion failure with static initializers

The CFGBlock::getLastCondition was not prepared for static initializer
branches.

This patch also revamps CFG unit tests. Earlier the lifetime of the AST
was smaller than the CFG. So all the AST pointers within the CFG blocks
were dangling. This was OK, since none of the tests dereferenced those
pointers. This was, however, a timed bomb. There were patches in the
past that were reverted partially due to this problem.

Differential revision: https://reviews.llvm.org/D71791

show more ...

[CFG] Introduce CFGElementRef, a wrapper that knows it's position in a CFGBlock

Previously, collecting CFGElements in a set was practially impossible, because
both CFGBlock::operator[] and both the

[CFG] Introduce CFGElementRef, a wrapper that knows it's position in a CFGBlock

Previously, collecting CFGElements in a set was practially impossible, because
both CFGBlock::operator[] and both the iterators returned it by value. One
workaround would be to collect the iterators instead, but they don't really
capture the concept of an element, and elements from different iterator types are incomparable.

This patch introduces CFGElementRef, a wrapper around a (CFGBlock, Index) pair,
and a variety of new iterators and iterator ranges to solve this problem.

I guess you could say that this patch took a couple iterations to get right :^)

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

llvm-svn: 368883

show more ...

Removed the test case added in D63538 due to windows buildbot failures

llvm-svn: 365209

Fix a buildbot failure due to the AST's lifetime ending before the test

llvm-svn: 365181

[analyzer][Dominators][NFC] Add unit tests

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

llvm-svn: 365179

[CFG] Add a new function to get the proper condition of a CFGBlock

getTerminatorCondition() returned a condition that may be outside of the
block, while the new function returns the proper one:

if

[CFG] Add a new function to get the proper condition of a CFGBlock

getTerminatorCondition() returned a condition that may be outside of the
block, while the new function returns the proper one:

if (A && B && C) {}

Return C instead of A && B && C.

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

llvm-svn: 365177

show more ...

[analyzer] Treat functions without run-time branches as "small".

Currently we always inline functions that have no branches, i.e. have exactly
three CFG blocks: ENTRY, some code, EXIT. This makes se

[analyzer] Treat functions without run-time branches as "small".

Currently we always inline functions that have no branches, i.e. have exactly
three CFG blocks: ENTRY, some code, EXIT. This makes sense because when there
are no branches, it means that there's no exponential complexity introduced
by inlining such function. Such functions also don't trigger various fundamental
problems with our inlining mechanism, such as the problem of inlined
defensive checks.

Sometimes the CFG may contain more blocks, but in practice it still has
linear structure because all directions (except, at most, one) of all branches
turned out to be unreachable. When this happens, still treat the function
as "small". This is useful, in particular, for dealing with C++17 if constexpr.

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

llvm-svn: 359531

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] Fix crash when building CFG with variable of incomplete type

Summary:
I've included a unit test with a function template containing a variable
of incomplete type. Clang compiles this with

[analyzer] Fix crash when building CFG with variable of incomplete type

Summary:
I've included a unit test with a function template containing a variable
of incomplete type. Clang compiles this without errors (the standard
does not require a diagnostic in this case). Without the fix, this case
triggers the crash.

Reviewers: klimek

Reviewed By: klimek

Subscribers: cfe-commits

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

llvm-svn: 297129

show more ...

CFGBuilder: Fix crash when visiting delete expression on dependent type

Summary:
CXXDeleteExpr::getDestroyedType() can return a null QualType if the destroyed
type is a dependent type. This patch pr

CFGBuilder: Fix crash when visiting delete expression on dependent type

Summary:
CXXDeleteExpr::getDestroyedType() can return a null QualType if the destroyed
type is a dependent type. This patch protects against this.

Reviewers: klimek

Subscribers: cfe-commits

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

llvm-svn: 288665

show more ...

clang/unittests/Analysis/CFGTest.cpp: Appease msc targets with -fno-delayed-template-parsing.

llvm-svn: 274879

CFGBuilder: Fix crash when visiting a range-based for over a dependent type

Summary:
CFG generation is expected to fail in this case, but it should not crash.

Also added a test that reproduces the

CFGBuilder: Fix crash when visiting a range-based for over a dependent type

Summary:
CFG generation is expected to fail in this case, but it should not crash.

Also added a test that reproduces the crash.

Reviewers: klimek

Subscribers: cfe-commits

Patch by Martin Boehme!

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

llvm-svn: 274834

show more ...