History log of /llvm-project/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp (Results 151 – 175 of 204)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 32dcb759 22-Jul-2022 Sam Estep <sam@samestep.com>

[clang][dataflow] Move NoopAnalysis from unittests to include

This patch moves `Analysis/FlowSensitive/NoopAnalysis.h` from `clang/unittests/` to `clang/include/clang/`, so that we can use it for do

[clang][dataflow] Move NoopAnalysis from unittests to include

This patch moves `Analysis/FlowSensitive/NoopAnalysis.h` from `clang/unittests/` to `clang/include/clang/`, so that we can use it for doing context-sensitive analysis.

Reviewed By: ymandel, gribozavr2, sgatev

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

show more ...


# f10d271a 04-Jul-2022 Eric Li <li.zhe.hua@gmail.com>

[clang][dataflow] Handle null pointers of type std::nullptr_t

Treat `std::nullptr_t` as a regular scalar type to avoid tripping
assertions when analyzing code that uses `std::nullptr_t`.

Differenti

[clang][dataflow] Handle null pointers of type std::nullptr_t

Treat `std::nullptr_t` as a regular scalar type to avoid tripping
assertions when analyzing code that uses `std::nullptr_t`.

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

show more ...


# 1d83a16b 30-Jun-2022 Sam Estep <sam@samestep.com>

[clang][dataflow] Replace TEST_F with TEST where possible

Many of our tests are currently written using `TEST_F` where the test fixture class doesn't have any `SetUp` or `TearDown` methods, and just

[clang][dataflow] Replace TEST_F with TEST where possible

Many of our tests are currently written using `TEST_F` where the test fixture class doesn't have any `SetUp` or `TearDown` methods, and just one helper method. In those cases, this patch deletes the class and pulls its method out into a standalone function, using `TEST` instead of `TEST_F`.

There are still a few test files leftover in `clang/unittests/Analysis/FlowSensitive/` that use `TEST_F`:

- `DataflowAnalysisContextTest.cpp` because the class contains a `Context` field which is used
- `DataflowEnvironmentTest.cpp` because the class contains an `Environment` field which is used
- `SolverTest.cpp` because the class contains a `Vals` field which is used
- `TypeErasedDataflowAnalysisTest.cpp` because there are several different classes which all share the same method name

Reviewed By: ymandel, sgatev

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

show more ...


# 8207c2a6 29-Jun-2022 Stanislav Gatev <sgatev@google.com>

[clang][dataflow] Handle `for` statements without conditions

Handle `for` statements without conditions.

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

Reviewed-by: xazax.hun, gribozavr2,

[clang][dataflow] Handle `for` statements without conditions

Handle `for` statements without conditions.

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

Reviewed-by: xazax.hun, gribozavr2, li.zhe.hua

show more ...


# b611376e 27-Jun-2022 Wei Yi Tee <wyt@google.com>

[clang][dataflow] Singleton pointer values for null pointers.

When a `nullptr` is assigned to a pointer variable, it is wrapped in a `ImplicitCastExpr` with cast kind `CK_NullTo(Member)Pointer`. Thi

[clang][dataflow] Singleton pointer values for null pointers.

When a `nullptr` is assigned to a pointer variable, it is wrapped in a `ImplicitCastExpr` with cast kind `CK_NullTo(Member)Pointer`. This patch assigns singleton pointer values representing null to these expressions.

For each pointee type, a singleton null `PointerValue` is created and stored in the `NullPointerVals` map of the `DataflowAnalysisContext` class. The pointee type is retrieved from the implicit cast expression, and used to initialise the `PointeeLoc` field of the `PointerValue`. The `PointeeLoc` created is not mapped to any `Value`, reflecting the absence of value indicated by null pointers.

Reviewed By: gribozavr2, sgatev, xazax.hun

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

show more ...


Revision tags: llvmorg-14.0.6
# e363c596 20-Jun-2022 Stanislav Gatev <sgatev@google.com>

[clang][dataflow] Extend flow condition in the body of a do/while loop

Extend flow condition in the body of a do/while loop.

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

Reviewed-by: gr

[clang][dataflow] Extend flow condition in the body of a do/while loop

Extend flow condition in the body of a do/while loop.

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

Reviewed-by: gribozavr2, xazax.hun

show more ...


# 83232099 17-Jun-2022 Stanislav Gatev <sgatev@google.com>

[clang][dataflow] Extend flow condition in the body of a for loop

Extend flow condition in the body of a for loop.

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


# ba53906c 16-Jun-2022 Stanislav Gatev <sgatev@google.com>

[clang][dataflow] Add support for comma binary operator

Add support for comma binary operator.

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

Reviewed-by: ymandel, xazax.hun


# 97d69cda 14-Jun-2022 Wei Yi Tee <wyt@google.com>

[clang][dataflow] Rename `getPointeeLoc` to `getReferentLoc` for ReferenceValue.

We distinguish between the referent location for `ReferenceValue` and pointee location for `PointerValue`. The former

[clang][dataflow] Rename `getPointeeLoc` to `getReferentLoc` for ReferenceValue.

We distinguish between the referent location for `ReferenceValue` and pointee location for `PointerValue`. The former must be non-empty but the latter may be empty in the case of a `nullptr`

Reviewed By: gribozavr2, sgatev

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

show more ...


Revision tags: llvmorg-14.0.5
# a1b2b7d9 08-Jun-2022 Wei Yi Tee <wyt@google.com>

[clang][dataflow] Remove IndirectionValue class, moving PointeeLoc field into PointerValue and ReferenceValue

This patch precedes a future patch to make PointeeLoc for PointerValue possibly empty (f

[clang][dataflow] Remove IndirectionValue class, moving PointeeLoc field into PointerValue and ReferenceValue

This patch precedes a future patch to make PointeeLoc for PointerValue possibly empty (for nullptr), by using a pointer instead of a reference type.
ReferenceValue should maintain a non-empty PointeeLoc reference.

Reviewed By: gribozavr2

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

show more ...


Revision tags: llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2
# 0e286b77 24-Feb-2022 Stanislav Gatev <sgatev@google.com>

[clang][dataflow] Add transfer functions for structured bindings

This is part of the implementation of the dataflow analysis framework.
See "[RFC] A dataflow analysis framework for Clang AST" on cfe

[clang][dataflow] Add transfer functions for structured bindings

This is part of the implementation of the dataflow analysis framework.
See "[RFC] A dataflow analysis framework for Clang AST" on cfe-dev.

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

Reviewed-by: ymandel, xazax.hun

show more ...


# 3682e22e 25-May-2022 Yitzhak Mandelbaum <yitzhakm@google.com>

[clang][dataflow] Improve handling of constructor initializers.

Currently, we assert that `CXXCtorInitializer`s are field initializers. Replace
the assertion with an early return. Otherwise, we cras

[clang][dataflow] Improve handling of constructor initializers.

Currently, we assert that `CXXCtorInitializer`s are field initializers. Replace
the assertion with an early return. Otherwise, we crash every time we process a
constructor with a non-field (e.g. base class) initializer.

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

show more ...


# 67136d0e 25-May-2022 Yitzhak Mandelbaum <yitzhakm@google.com>

[clang][dataflow] Remove private-field filtering from `StorageLocation` creation.

The API for `AggregateStorageLocation` does not allow for missing fields (it asserts). Therefore, it is incorrect to

[clang][dataflow] Remove private-field filtering from `StorageLocation` creation.

The API for `AggregateStorageLocation` does not allow for missing fields (it asserts). Therefore, it is incorrect to filter out any fields at location-creation time which may be accessed by the code. Currently, we limit filtering to private, base-calss fields on the assumption that those can never be accessed. However, `friend` declarations can invalidate that assumption, thereby breaking our invariants.

This patch removes said field filtering to avoid violating the invariant of "no missing fields" for `AggregateStorageLocation`.

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

show more ...


# 5520c583 25-May-2022 Eric Li <li.zhe.hua@gmail.com>

[clang][dataflow] Fix incorrect CXXThisExpr pointee for lambdas

When constructing the `Environment`, the `this` pointee is established
for a `CXXMethodDecl` by looking at its parent. However, inside

[clang][dataflow] Fix incorrect CXXThisExpr pointee for lambdas

When constructing the `Environment`, the `this` pointee is established
for a `CXXMethodDecl` by looking at its parent. However, inside of
lambdas, a `CXXThisExpr` refers to the captured `this` coming from the
enclosing member function.

When establishing the `this` pointee for a function, we check whether
the function is a lambda, and check for an enclosing member function
to establish the `this` pointee storage location.

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

show more ...


# 33b598a8 25-May-2022 Eric Li <li.zhe.hua@gmail.com>

[clang][dataflow] Relax assert on existence of `this` pointee storage

Support for unions is incomplete (per 99f7d55e) and the `this` pointee
storage location is not set for unions. The assert in
`Vi

[clang][dataflow] Relax assert on existence of `this` pointee storage

Support for unions is incomplete (per 99f7d55e) and the `this` pointee
storage location is not set for unions. The assert in
`VisitCXXThisExpr` is then guaranteed to trigger when analyzing member
functions of a union.

This commit changes the assert to an early-return. Any expression may
be undefined, and so having a value for the `CXXThisExpr` is not a
postcondition of the transfer function.

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

show more ...


# 2f93bbb9 24-May-2022 Yitzhak Mandelbaum <yitzhakm@google.com>

[clang][dataflow] Relax `Environment` comparison operation.

Ignore `MemberLocToStruct` in environment comparison. As an ancillary data
structure, including it is redundant. We also can generate envi

[clang][dataflow] Relax `Environment` comparison operation.

Ignore `MemberLocToStruct` in environment comparison. As an ancillary data
structure, including it is redundant. We also can generate environments which
differ in their `MemberLocToStruct` but are otherwise equivalent.

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

show more ...


# 5bbef2e3 17-May-2022 Eric Li <li.zhe.hua@gmail.com>

[clang][dataflow] Fix double visitation of nested logical operators

Sub-expressions that are logical operators are not spelled out
separately in basic blocks, so we need to manually visit them when

[clang][dataflow] Fix double visitation of nested logical operators

Sub-expressions that are logical operators are not spelled out
separately in basic blocks, so we need to manually visit them when we
encounter them. We do this in both the `TerminatorVisitor`
(conditionally) and the `TransferVisitor` (unconditionally), which can
cause cause an expression to be visited twice when the binary
operators are nested 2+ times.

This changes the visit in `TransferVisitor` to check if it has been
evaluated before trying to visit the sub-expression.

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

show more ...


# eb2131bd 14-Apr-2022 Yitzhak Mandelbaum <yitzhakm@google.com>

[clang][dataflow] Do not crash on missing `Value` for struct-typed variable init.

Remove constraint that an initializing expression of struct type must have an
associated `Value`. This invariant is

[clang][dataflow] Do not crash on missing `Value` for struct-typed variable init.

Remove constraint that an initializing expression of struct type must have an
associated `Value`. This invariant is not and will not be guaranteed by the
framework, because of potentially uninitialized fields.

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

show more ...


# bbcf11f5 05-Apr-2022 Yitzhak Mandelbaum <yitzhakm@google.com>

[clang][dataflow] Weaken abstract comparison to enable loop termination.

Currently, when the framework is used with an analysis that does not override
`compareEquivalent`, it does not terminate for

[clang][dataflow] Weaken abstract comparison to enable loop termination.

Currently, when the framework is used with an analysis that does not override
`compareEquivalent`, it does not terminate for most loops. The root cause is the
interaction of (the default implementation of) environment comparison
(`compareEquivalent`) and the means by which locations and values are
allocated. Specifically, the creation of certain values (including: reference
and pointer values; merged values) results in allocations of fresh locations in
the environment. As a result, analysis of even trivial loop bodies produces
different (if isomorphic) environments, on identical inputs. At the same time,
the default analysis relies on strict equality (versus some relaxed notion of
equivalence). Together, when the analysis compares these isomorphic, yet
unequal, environments, to determine whether the successors of the given block
need to be (re)processed, the result is invariably "yes", thus preventing loop
analysis from reaching a fixed point.

There are many possible solutions to this problem, including equivalence that is
less than strict pointer equality (like structural equivalence) and/or the
introduction of an explicit widening operation. However, these solutions will
require care to be implemented correctly. While a high priority, it seems more
urgent that we fix the current default implentation to allow
termination. Therefore, this patch proposes, essentially, to change the default
comparison to trivally equate any two values. As a result, we can say precisely
that the analysis will process the loop exactly twice -- once to establish an
initial result state and the second to produce an updated result which will
(always) compare equal to the previous. While clearly unsound -- we are not
reaching a fix point of the transfer function, in practice, this level of
analysis will find many practical issues where a single iteration of the loop
impacts abstract program state.

Note, however, that the change to the default `merge` operation does not affect
soundness, because the framework already produces a fresh (sound) abstraction of
the value when the two values are distinct. The previous setting was overly
conservative.

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

show more ...


# d002495b 04-Apr-2022 Yitzhak Mandelbaum <yitzhakm@google.com>

[clang][dataflow] Support integral casts

Adds support for implicit casts `CK_IntegralCast` and `CK_IntegralToBoolean`.

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


# 506ec85b 01-Apr-2022 Yitzhak Mandelbaum <yitzhakm@google.com>

[clang][dataflow] Add support for clang's `__builtin_expect`.

This patch adds basic modeling of `__builtin_expect`, just to propagate the
(first) argument, making the call transparent.

Driveby: add

[clang][dataflow] Add support for clang's `__builtin_expect`.

This patch adds basic modeling of `__builtin_expect`, just to propagate the
(first) argument, making the call transparent.

Driveby: adds tests for proper handling of other builtins.

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

show more ...


# 01db1036 28-Mar-2022 Yitzhak Mandelbaum <yitzhakm@google.com>

[clang][dataflow] Add support for correlation of boolean (tracked) values

This patch extends the join logic for environments to explicitly handle
boolean values. It creates the disjunction of both s

[clang][dataflow] Add support for correlation of boolean (tracked) values

This patch extends the join logic for environments to explicitly handle
boolean values. It creates the disjunction of both source values, guarded by the
respective flow conditions from each input environment. This change allows the
framework to reason about boolean correlations across multiple branches (and
subsequent joins).

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

show more ...


# ef1e1b31 25-Mar-2022 Yitzhak Mandelbaum <yitzhakm@google.com>

[clang][dataflow] Add support for (built-in) (in)equality operators

Adds logical interpretation of built-in equality operators, `==` and `!=`.s

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

[clang][dataflow] Add support for (built-in) (in)equality operators

Adds logical interpretation of built-in equality operators, `==` and `!=`.s

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

show more ...


# 36d4e844 23-Mar-2022 Yitzhak Mandelbaum <yitzhakm@google.com>

[clang][dataflow] Fix handling of base-class fields.

Currently, the framework does not track derived class access to base
fields. This patch adds that support and a corresponding test.

Differential

[clang][dataflow] Fix handling of base-class fields.

Currently, the framework does not track derived class access to base
fields. This patch adds that support and a corresponding test.

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

show more ...


# cf63e9d4 11-Mar-2022 Stanislav Gatev <sgatev@google.com>

[clang][dataflow] Add support for nested composite bool expressions

This is part of the implementation of the dataflow analysis framework.
See "[RFC] A dataflow analysis framework for Clang AST" on

[clang][dataflow] Add support for nested composite bool expressions

This is part of the implementation of the dataflow analysis framework.
See "[RFC] A dataflow analysis framework for Clang AST" on cfe-dev.

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

show more ...


123456789