History log of /llvm-project/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp (Results 101 – 125 of 204)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# d3632486 28-Jun-2023 Martin Braenne <mboehme@google.com>

[clang][dataflow] Initialize fields of anonymous records correctly.

Previously, the newly added test would crash.

Depends On D153851

Reviewed By: gribozavr2

Differential Revision: https://reviews

[clang][dataflow] Initialize fields of anonymous records correctly.

Previously, the newly added test would crash.

Depends On D153851

Reviewed By: gribozavr2

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

show more ...


# abc83674 28-Jun-2023 Martin Braenne <mboehme@google.com>

[clang][dataflow] Don't crash if copy constructor arg doesn't have a storage location.

I accidentally used `cast` instead of `cast_or_null`.

Reviewed By: sammccall, xazax.hun

Differential Revision

[clang][dataflow] Don't crash if copy constructor arg doesn't have a storage location.

I accidentally used `cast` instead of `cast_or_null`.

Reviewed By: sammccall, xazax.hun

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

show more ...


# d04b1989 28-Jun-2023 Martin Braenne <mboehme@google.com>

[clang][dataflow] Add a test that we can access fields of anonymous records.

Reviewed By: sammccall, ymandel, gribozavr2, xazax.hun

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


# f2123af1 20-Jun-2023 Martin Braenne <mboehme@google.com>

[clang][dataflow] Perform deep copies in copy and move operations.

This serves two purposes:

- Because, today, we only copy the `StructValue`, modifying the destination of
the copy also modifies

[clang][dataflow] Perform deep copies in copy and move operations.

This serves two purposes:

- Because, today, we only copy the `StructValue`, modifying the destination of
the copy also modifies the source. This is demonstrated by the new checks
added to `CopyConstructor` and `MoveConstructor`, which fail without the
deep copy.

- It lays the groundwork for eliminating the redundancy between
`AggregateStorageLocation` and `StructValue`, which will happen as part of the
ongoing migration to strict handling of value categories (seeo
https://discourse.llvm.org/t/70086 for details). This will involve turning
`StructValue` into essentially just a wrapper for `AggregateStorageLocation`;
under this scheme, the current "shallow" copy (copying a `StructValue` from
one `AggregateStorageLocation` to another) will no longer be possible.

Because we now perform deep copies, tests need to perform a deep equality
comparison instead of just comparing for equal identity of the `StructValue`s.
The new function `recordsEqual()` provides such a deep equality comparison.

Reviewed By: xazax.hun

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

show more ...


# 762cb1d3 15-Jun-2023 Martin Braenne <mboehme@google.com>

[clang][dataflow] Create `Value`s for integer literals.

This patch includes a test that fails without the fix.

I discovered that we weren't creating `Value`s for integer literals when, in a
differe

[clang][dataflow] Create `Value`s for integer literals.

This patch includes a test that fails without the fix.

I discovered that we weren't creating `Value`s for integer literals when, in a
different patch, I tried to overwrite the value of a struct field with a literal
for the purposes of a test and was surprised to find that the struct compared
the same before and after the assignment.

This functionality therefore seems useful at least for tests, but is probably
also useful for actual analysis of code.

Reviewed By: ymandel, xazax.hun, gribozavr2

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

show more ...


# 3f31d320 12-Jun-2023 Martin Braenne <mboehme@google.com>

[clang][dataflow] Model pointer value for builtin functions.

This fixes a false positive in the Crubit nullability verification.

Reviewed By: gribozavr2

Differential Revision: https://reviews.llvm

[clang][dataflow] Model pointer value for builtin functions.

This fixes a false positive in the Crubit nullability verification.

Reviewed By: gribozavr2

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

show more ...


Revision tags: llvmorg-16.0.6, llvmorg-16.0.5
# 7f6c3a90 25-May-2023 Martin Braenne <mboehme@google.com>

[clang][dataflow] Fix a crash in `getLogicOperatorSubExprValue()`.

This patch adds a test that crashes without the fix.

Reviewed By: ymandel

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


# 64413584 23-May-2023 Martin Braenne <mboehme@google.com>

[clang][dataflow] Add support for return values of reference type.

This patch changes the way `Environment::ReturnLoc` is set: Whereas previously it was set by the caller, it is now set by the calle

[clang][dataflow] Add support for return values of reference type.

This patch changes the way `Environment::ReturnLoc` is set: Whereas previously it was set by the caller, it is now set by the callee (obviously, as we otherwise would not be able to return references).

The patch also introduces `Environment::ReturnVal`, which is used for non-reference-type return values. This allows these to be handled with the correct value category semantics; see also https://discourse.llvm.org/t/70086, which describes the ongoing migration to strict value category semantics.

Depends On D150776

Reviewed By: ymandel, xazax.hun

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

show more ...


Revision tags: llvmorg-16.0.4
# 1a42f795 15-May-2023 Martin Braenne <mboehme@google.com>

[clang][dataflow] Don't analyze templated declarations.

Attempting to analyze templated code doesn't have a good cost-benefit ratio. We
have so far done a best-effort attempt at this, but maintainin

[clang][dataflow] Don't analyze templated declarations.

Attempting to analyze templated code doesn't have a good cost-benefit ratio. We
have so far done a best-effort attempt at this, but maintaining this support has
an ongoing high maintenance cost because the AST for templates can violate a lot
of the invariants that otherwise hold for the AST of concrete code. As just one
example, in concrete code the operand of a UnaryOperator '*' is always a prvalue
(https://godbolt.org/z/s3e5xxMd1), but in templates this isn't true
(https://godbolt.org/z/6W9xxGvoM).

Further rationale for not analyzing templates:

* The semantics of a template itself are weakly defined; semantics can depend
strongly on the concrete template arguments. Analyzing the template itself (as
opposed to an instantiation) therefore has limited value.

* Analyzing templates requires a lot of special-case code that isn't necessary
for concrete code because dependent types are hard to deal with and the AST
violates invariants that otherwise hold for concrete code (see above).

* There's precedent in that neither Clang Static Analyzer nor the flow-sensitive
warnings in Clang (such as uninitialized variables) support analyzing
templates.

Reviewed By: gribozavr2, xazax.hun

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

show more ...


# 0c852dc8 08-May-2023 Martin Braenne <mboehme@google.com>

[clang][dataflow][NFC] Remove `SkipPast` param from `getValue(const ValueDecl &)`.

This parameter was already a no-op, so removing it doesn't change behavior.

Reviewed By: ymandel

Differential Rev

[clang][dataflow][NFC] Remove `SkipPast` param from `getValue(const ValueDecl &)`.

This parameter was already a no-op, so removing it doesn't change behavior.

Reviewed By: ymandel

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

show more ...


# 9940fac7 08-May-2023 Martin Braenne <mboehme@google.com>

[clang][dataflow][NFC] Remove `SkipPast` parameter from `getStorageLocation(const ValueDecl &).

This parameter was already a no-op, so removing it doesn't change behavior.

Depends On D149144

Revie

[clang][dataflow][NFC] Remove `SkipPast` parameter from `getStorageLocation(const ValueDecl &).

This parameter was already a no-op, so removing it doesn't change behavior.

Depends On D149144

Reviewed By: ymandel, xazax.hun, gribozavr2

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

show more ...


# bfbe1378 04-May-2023 Martin Braenne <mboehme@google.com>

[clang][dataflow] Eliminate intermediate `ReferenceValue`s from `Environment::DeclToLoc`.

For the wider context of this change, see the RFC at
https://discourse.llvm.org/t/70086.

After this change,

[clang][dataflow] Eliminate intermediate `ReferenceValue`s from `Environment::DeclToLoc`.

For the wider context of this change, see the RFC at
https://discourse.llvm.org/t/70086.

After this change, global and local variables of reference type are associated
directly with the `StorageLocation` of the referenced object instead of the
`StorageLocation` of a `ReferenceValue`.

Some tests that explicitly check for an existence of `ReferenceValue` for a
variable of reference type have been modified accordingly.

As discussed in the RFC, I have added an assertion to `Environment::join()` to
check that if both environments contain an entry for the same declaration in
`DeclToLoc`, they both map to the same `StorageLocation`. As discussed in
https://discourse.llvm.org/t/70086/5, this also necessitates removing
declarations from `DeclToLoc` when they go out of scope.

In the RFC, I proposed a gradual migration for this change, but it appears
that all of the callers of `Environment::setStorageLocation(const ValueDecl &,
SkipPast` are in the dataflow framework itself, and that there are only a few of
them.

As this is the function whose semantics are changing in a way that callers
potentially need to adapt to, I've decided to change the semantics of the
function directly.

The semantics of `getStorageLocation(const ValueDecl &, SkipPast SP` now no
longer depend on the behavior of the `SP` parameter. (There don't appear to be
any callers that use `SkipPast::ReferenceThenPointer`, so I've added an
assertion that forbids this usage.)

This patch adds a default argument for the `SP` parameter and removes the
explicit `SP` argument at the callsites that are touched by this change. A
followup patch will remove the argument from the remaining callsites,
allowing the `SkipPast` parameter to be removed entirely. (I don't want to do
that in this patch so that semantics-changing changes can be reviewed separately
from semantics-neutral changes.)

Reviewed By: ymandel, xazax.hun, gribozavr2

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

show more ...


# 791b0fd0 03-May-2023 Kinuko Yasuda <kinuko@google.com>

[clang][dataflow] Change PruneTriviallyFalseEdges for building CFG

Keeping this false could end up with extra iterations on a lot of loops
that aren't real ones (e.g. they could be a do-while-false

[clang][dataflow] Change PruneTriviallyFalseEdges for building CFG

Keeping this false could end up with extra iterations on a lot of loops
that aren't real ones (e.g. they could be a do-while-false for macros),
and makes the analyses very slow.

This patch changes the default for
CFG::BuildOptions.PruneTriviallyFalseEdges to true to avoid it.

Reviewed By: ymandel, xazax.hun, gribozavr2

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

show more ...


Revision tags: llvmorg-16.0.3
# 2cdb6b84 02-May-2023 Samira Bazuzi <bazuzi@google.com>

[clang][dataflow] Expose DataflowAnalysisContext from DataflowEnvironment.

This will eliminate the need for more pass-through APIs. Also replace pass-through usages with this exposure.

Reviewed By:

[clang][dataflow] Expose DataflowAnalysisContext from DataflowEnvironment.

This will eliminate the need for more pass-through APIs. Also replace pass-through usages with this exposure.

Reviewed By: ymandel, gribozavr2, xazax.hun

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

show more ...


Revision tags: llvmorg-16.0.2
# d9e71733 18-Apr-2023 Martin Braenne <mboehme@google.com>

[clang][dataflow] Associate `FunctionToPointerDecay` nodes with a value.

To ensure that we have a pointee for the `PointerValue`, we also create
storage locations for `FunctionDecl`s referenced in t

[clang][dataflow] Associate `FunctionToPointerDecay` nodes with a value.

To ensure that we have a pointee for the `PointerValue`, we also create
storage locations for `FunctionDecl`s referenced in the function under analysis.

Reviewed By: gribozavr2

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

show more ...


# 6ab900f8 18-Apr-2023 Martin Braenne <mboehme@google.com>

[clang][dataflow] Add support for new expressions.

Reviewed By: xazax.hun, gribozavr2

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


Revision tags: llvmorg-16.0.1
# 5acd29eb 23-Mar-2023 Martin Braenne <mboehme@google.com>

[clang][dataflow] Fix crash when RHS of `&&` or `||` calls `noreturn` func.

The crash happened because the transfer fucntion for `&&` and `||`
unconditionally tried to retrieve the value of the RHS.

[clang][dataflow] Fix crash when RHS of `&&` or `||` calls `noreturn` func.

The crash happened because the transfer fucntion for `&&` and `||`
unconditionally tried to retrieve the value of the RHS. However, if the RHS
is unreachable, there is no environment for it, and trying to retrieve the
operand's value causes an assertion failure.

See also the comments in the code for further details.

Reviewed By: xazax.hun, ymandel, sgatev, gribozavr2

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

show more ...


Revision tags: llvmorg-16.0.0, llvmorg-16.0.0-rc4
# 96d035c1 27-Feb-2023 Paul Semel <semelpaul@gmail.com>

[clang][dataflow] unnamed bitfields should be discarded in InitListExpr

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


# e6e753d1 22-Feb-2023 Paul Semel <paulsemel@google.com>

[clang][dataflow] Fix wrong assert for CXXConstructExpr

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


Revision tags: llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7
# 02562804 03-Jan-2023 Yitzhak Mandelbaum <yitzhakm@google.com>

[clang][dataflow] Fix handling of `DeclRefExpr`s to `BindingDecl`s.

The invariants around `ReferenceValues` are subtle (arguably, too much so). That
includes that we need to take care not to double

[clang][dataflow] Fix handling of `DeclRefExpr`s to `BindingDecl`s.

The invariants around `ReferenceValues` are subtle (arguably, too much so). That
includes that we need to take care not to double wrap them -- in cases where we
wrap a loc in an `ReferenceValue` we need to be sure that the pointee isn't
already a `ReferenceValue`. `BindingDecl` introduces another situation in which
this can arise. Previously, the code did not properly handle `BindingDecl`,
resulting in double-wrapped values, which broke other invariants (at least, that
struct values have an `AggregateStorageLocation`).

This patch adjusts the interpretation of `DeclRefExpr` to take `BindingDecl`'s
peculiarities into account. It also fixes the two tests which should have caught
this issue but were themselves (subtly) buggy.

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

show more ...


# b84ac96a 24-Jan-2023 Yitzhak Mandelbaum <yitzhakm@google.com>

[clang][dataflow] Fix bug in handling of reference-typed fields.

This patch fixes a subtle bug in how we create lvalues to reference-typed
fields. In the rare case that the field is umodeled because

[clang][dataflow] Fix bug in handling of reference-typed fields.

This patch fixes a subtle bug in how we create lvalues to reference-typed
fields. In the rare case that the field is umodeled because of the depth limit
on field modeling, the lvalue created can be malformed. This patch prevents that
and adds some related assertions to other code dealing with lvalues for
references.

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

show more ...


# 6ad0788c 14-Jan-2023 Kazu Hirata <kazu@google.com>

[clang] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to remove #include "llvm/ADT/Optional.h".

This is p

[clang] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to remove #include "llvm/ADT/Optional.h".

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...


# a1580d7b 14-Jan-2023 Kazu Hirata <kazu@google.com>

[clang] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Option

[clang] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Optional with
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...


# 3ce03c42 09-Jan-2023 Yitzhak Mandelbaum <yitzhakm@google.com>

[clang][dataflow] Fix 2 bugs in `MemberExpr` interpretation.

There were two (small) bugs causing crashes in the analysis. This patch fixes both of them.

1. An enum value was accessed as a class me

[clang][dataflow] Fix 2 bugs in `MemberExpr` interpretation.

There were two (small) bugs causing crashes in the analysis. This patch fixes both of them.

1. An enum value was accessed as a class member. Now, the engine gracefully
ignores such member expressions.

2. Field access in `MemberExpr` of struct/class-typed global variables. Analysis
didn't interpret fields of global vars, because the vars were initialized before
the fields were added to the "allowlist". Now, the allowlist is set _before_
init of globals.

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

show more ...


# 264976d9 27-Dec-2022 Yitzhak Mandelbaum <yitzhakm@google.com>

[clang][dataflow] Unify `TransferOptions` and `DataflowAnalysisContext::Options`.

Merges `TransferOptions` into the newly-introduced
`DataflowAnalysisContext::Options` and removes explicit parameter

[clang][dataflow] Unify `TransferOptions` and `DataflowAnalysisContext::Options`.

Merges `TransferOptions` into the newly-introduced
`DataflowAnalysisContext::Options` and removes explicit parameter for
`TransferOptions`, relying instead on the common options carried by the analysis
context. Given that there was no intent to allow different options between calls
to `transfer`, a common value for the options is preferable.

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

show more ...


123456789