This is important if the first use of a StatusOr (or Status) is in a
conditional statement, we need a stable value for `ok` from outside of
the conditional statement to make sure we don't use a different variable
in every branch.
Reviewers: jvoung, Xazax-hun
Reviewed By: jvoung
Pull Request: https://github.com/llvm/llvm-project/pull/163898
`absl::StatusOr::status` allows extraction of the status associated with
a StatusOr value. That can also be used to check whether the StatusOr
has a value or not.
This makes sure code like this is checked properly:
```cpp
int target(absl::StatusOr<int> SOR) {
if (SOR.status().ok())
return *SOR;
return 0;
}
```
This model implements a dataflow analysis for reporting instances of
unchecked use of absl::StatusOr values. It makes sure that every use
the value of a StatusOr object is dominated by a check that the
StatusOr object is ok.
This is an example of code that will be flagged by the analysis:
```cpp
int f(absl::StatusOr<int> SOR) {
return SOR.value();
}
```
This is an example of code that will not be flagged by the analysis:
```cpp
int f(absl::StatusOr<int> SOR) {
if (SOR.ok())
return SOR.value();
return 0;
}
```
This model has successfully been used by Google for some time now.
This is the initial commit that adds the simplest possible model, that
only models calls to `ok()` and checks for unsafe accesses. I will add
more fidelity to the model in follow up changes.
The test setup is notable in that it has an extra indirection. This is
because we have an internal model that extends the model we intend to
upstream, in order to model special constructs only found in our code
base. The parametrized test allows us (and anyone who chooses to do
this) to make sure our extensions do not break the base functionality.
RFC:
https://discourse.llvm.org/t/rfc-abseil-unchecked-statusor-use-check/87998
