[clang][dataflow] Analyze calls to in-TU functions

This patch adds initial support for context-sensitive analysis of simple functions whose definition is available in the translation unit, guarded b

[clang][dataflow] Analyze calls to in-TU functions

This patch adds initial support for context-sensitive analysis of simple functions whose definition is available in the translation unit, guarded by the `ContextSensitive` flag in the new `TransferOptions` struct. When this option is true, the `VisitCallExpr` case in the builtin transfer function has a fallthrough case which checks for a direct callee with a body. In that case, it constructs a CFG from that callee body, uses the new `pushCall` method on the `Environment` to make an environment to analyze the callee, and then calls `runDataflowAnalysis` with a `NoopAnalysis` (disabling context-sensitive analysis on that sub-analysis, to avoid problems with recursion). After the sub-analysis completes, the `Environment` from its exit block is simply assigned back to the environment at the callsite.

The `pushCall` method (which currently only supports non-method functions with some restrictions) maps the `SourceLocation`s for all the parameters to the existing source locations for the corresponding arguments from the callsite.

This patch adds a few tests to check that this context-sensitive analysis works on simple functions. More sophisticated functionality will be added later; the most important next step is to explicitly model context in some fields of the `DataflowAnalysisContext` class, as mentioned in a `FIXME` comment in the `pushCall` implementation.

Reviewed By: ymandel, xazax.hun

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

show more ...

Revert "[clang][dataflow] Analyze calls to in-TU functions"

This reverts commit fa2b83d07ecab3b24b4c5ee2e7dc4b6bbc895317.

[clang][dataflow] Analyze calls to in-TU functions

Depends On D130305

This patch adds initial support for context-sensitive analysis of simple functions whose definition is available in the transla

[clang][dataflow] Analyze calls to in-TU functions

Depends On D130305

This patch adds initial support for context-sensitive analysis of simple functions whose definition is available in the translation unit, guarded by the `ContextSensitive` flag in the new `TransferOptions` struct. When this option is true, the `VisitCallExpr` case in the builtin transfer function has a fallthrough case which checks for a direct callee with a body. In that case, it constructs a CFG from that callee body, uses the new `pushCall` method on the `Environment` to make an environment to analyze the callee, and then calls `runDataflowAnalysis` with a `NoopAnalysis` (disabling context-sensitive analysis on that sub-analysis, to avoid problems with recursion). After the sub-analysis completes, the `Environment` from its exit block is simply assigned back to the environment at the callsite.

The `pushCall` method (which currently only supports non-method functions with some restrictions) first calls `initGlobalVars`, then maps the `SourceLocation`s for all the parameters to the existing source locations for the corresponding arguments from the callsite.

This patch adds a few tests to check that this context-sensitive analysis works on simple functions. More sophisticated functionality will be added later; the most important next step is to explicitly model context in some fields of the `DataflowAnalysisContext` class, as mentioned in a `TODO` comment in the `pushCall` implementation.

Reviewed By: ymandel, xazax.hun

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

show more ...

[clang][dataflow] Rename iterators from IT to It

The latter way to abbreviate is a lot more common in the LLVM codebase.

Reviewed By: sgatev, xazax.hun

Differential Revision: https://reviews.llvm.

[clang][dataflow] Rename iterators from IT to It

The latter way to abbreviate is a lot more common in the LLVM codebase.

Reviewed By: sgatev, xazax.hun

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

show more ...

[clang] Use value instead of getValue (NFC)

[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 ...

[clang][dataflow] Add API to separate analysis from diagnosis

This patch adds an optional `PostVisitStmt` parameter to the `runTypeErasedDataflowAnalysis` function, which does one more pass over all

[clang][dataflow] Add API to separate analysis from diagnosis

This patch adds an optional `PostVisitStmt` parameter to the `runTypeErasedDataflowAnalysis` function, which does one more pass over all statements in the CFG after a fixpoint is reached. It then defines a `diagnose` method for the optional model in a new `UncheckedOptionalAccessDiagnosis` class, but only integrates that into the tests and not the actual optional check for `clang-tidy`. That will be done in a followup patch.

The primary motivation is to separate the implementation of the unchecked optional access check into two parts, to allow for further refactoring of just the model part later, while leaving the checking part alone. Currently there is duplication between the `transferUnwrapCall` and `diagnoseUnwrapCall` functions, but that will be dealt with in the followup.

Because diagnostics are now all gathered into one collection rather than being populated at each program point like when computing a fixpoint, this patch removes the usage of `Pair` and `UnorderedElementsAre` from the optional model tests, and instead modifies all their expectations to simply check the stringified set of diagnostics against a single string, either `"safe"` or some concatenation of `"unsafe: input.cc:y:x"`. This is not ideal as it loses any connection to the `/*[[check]]*/` annotations in the source strings, but it does still retain the source locations from the diagnostic strings themselves.

Reviewed By: sgatev, gribozavr2, xazax.hun

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

show more ...

[clang] Don't use Optional::hasValue (NFC)

This patch replaces Optional::hasValue with the implicit cast to bool
in conditionals only.

Revert "Don't use Optional::hasValue (NFC)"

This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.

Don't use Optional::hasValue (NFC)

[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 ...

[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

[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 ...

[clang][dataflow] Make limit on fixpoint-algorithm iterations proportional to size of CFG.

Currently, the maximum number of iterations of the loop for finding the fixpoint
of the dataflow analysis i

[clang][dataflow] Make limit on fixpoint-algorithm iterations proportional to size of CFG.

Currently, the maximum number of iterations of the loop for finding the fixpoint
of the dataflow analysis is set at 2^16. When things go wrong in an analysis,
this can be far too large. This patch changes the limit to be proportional to
the size of the CFG, which will generally be far smaller than 2^16 (while still
maintaining 2^16 as the absolute limit).

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

show more ...

[clang][dataflow] Weaken guard to only check for storage location

Weaken the guard for whether a sub-expression has been evaluated to
only check for the storage location, instead of checking for the

[clang][dataflow] Weaken guard to only check for storage location

Weaken the guard for whether a sub-expression has been evaluated to
only check for the storage location, instead of checking for the
value. It should be sufficient to check for the storage location, as
we don't necessarily guarantee that a value will be set for the
location (although this is currently true right now).

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

show more ...

[clang][dataflow] Centralize expression skipping logic

A follow-up to 62b2a47 to centralize the logic that skips expressions
that the CFG does not emit. This allows client code to avoid
sprinkling t

[clang][dataflow] Centralize expression skipping logic

A follow-up to 62b2a47 to centralize the logic that skips expressions
that the CFG does not emit. This allows client code to avoid
sprinkling this logic everywhere.

Add redirects in the transfer function to similarly skip such
expressions by forwarding the visit to the sub-expression.

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

show more ...

[clang][dataflow] Only skip ExprWithCleanups when visiting terminators

`IgnoreParenImpCasts` will remove implicit casts to bool
(e.g. `PointerToBoolean`), such that the resulting expression may not

[clang][dataflow] Only skip ExprWithCleanups when visiting terminators

`IgnoreParenImpCasts` will remove implicit casts to bool
(e.g. `PointerToBoolean`), such that the resulting expression may not
be of the `bool` type. The `cast_or_null<BoolValue>` in
`extendFlowCondition` will then trigger an assert, as the pointer
expression will not have a `BoolValue`.

Instead, we only skip `ExprWithCleanups` and `ParenExpr` nodes, as the
CFG does not emit them.

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

show more ...

[clang][dataflow] Ensure well-formed flow conditions.

Ensure that the expressions associated with terminators are associated with a
value. Otherwise, we can generate degenerate flow conditions, wher

[clang][dataflow] Ensure well-formed flow conditions.

Ensure that the expressions associated with terminators are associated with a
value. Otherwise, we can generate degenerate flow conditions, where both
branches share the same condition.

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

show more ...

[clang][dataflow] Allow disabling built-in transfer functions for CFG terminators

Terminators are handled specially in the transfer functions so we need an
additional check on whether the analysis h

[clang][dataflow] Allow disabling built-in transfer functions for CFG terminators

Terminators are handled specially in the transfer functions so we need an
additional check on whether the analysis has disabled built-in transfer
functions.

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

show more ...

[clang][dataflow] Extend flow conditions from block terminators

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

[clang][dataflow] Extend flow conditions from block terminators

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

Reviewed-by: ymandel, xazax.hun

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

show more ...

[clang][dataflow] Add transfer functions for logical and, or, not.

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

[clang][dataflow] Add transfer functions for logical and, or, not.

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

Reviewed-by: xazax.hun

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

show more ...

[clang][dataflow] Enable comparison of distinct values in Environment

Make specializations of `DataflowAnalysis` extendable with domain-specific
logic for comparing distinct values when comparing en

[clang][dataflow] Enable comparison of distinct values in Environment

Make specializations of `DataflowAnalysis` extendable with domain-specific
logic for comparing distinct values when comparing environments.

This includes a breaking change to the `runDataflowAnalysis` interface
as the return type is now `llvm::Expected<...>`.

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

Reviewed-by: ymandel, xazax.hun

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

show more ...

[clang][dataflow] Allow clients to disable built-in transfer functions.

These built-in functions build the (sophisticated) model of the code's
memory. This model isn't used by all analyses, so we pr

[clang][dataflow] Allow clients to disable built-in transfer functions.

These built-in functions build the (sophisticated) model of the code's
memory. This model isn't used by all analyses, so we provide for disabling it to
avoid incurring the costs associated with its construction.

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

show more ...

[clang][dataflow] Enable merging distinct values in Environment::join

Make specializations of `DataflowAnalysis` extendable with domain-specific
logic for merging distinct values when joining enviro

[clang][dataflow] Enable merging distinct values in Environment::join

Make specializations of `DataflowAnalysis` extendable with domain-specific
logic for merging distinct values when joining environments. This could be
a strict lattice join or a more general widening operation.

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

Reviewed-by: xazax.hun

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

show more ...

[clang][dataflow] Avoid MaxIterations overflow

unsigned is technically guaranteed to be only 16 bits in which case 1 << 16 would wrap around to zero.

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

[clang][dataflow] Avoid MaxIterations overflow

unsigned is technically guaranteed to be only 16 bits in which case 1 << 16 would wrap around to zero.

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

show more ...