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