================
@@ -985,6 +985,20 @@ auto buildTransferMatchSwitch() {
           isOptionalMemberCallWithNameMatcher(hasName("isNull")),
           transferOptionalIsNullCall)
 
+      // NullableValue::makeValue, NullableValue::makeValueInplace
+      // Only NullableValue has these methods, but this
+      // will also pass for other types
+      .CaseOfCFGStmt<CXXMemberCallExpr>(
+          isOptionalMemberCallWithNameMatcher(
+              hasAnyName("makeValue", "makeValueInplace")),
+          [](const CXXMemberCallExpr *E, const MatchFinder::MatchResult &,
+             LatticeTransferState &State) {
+            if (RecordStorageLocation *Loc =
+                    getImplicitObjectLocation(*E, State.Env)) {
+              setHasValue(*Loc, State.Env.getBoolLiteralValue(true), 
State.Env);
+            }
+          })
+
----------------
BaLiKfromUA wrote:

I started experimenting with implementing the mentioned configuration and have 
a doubt that I would like to talk about.

**What is the preferred way to pass `UncheckedOptionalAccessModelOptions` 
inside `UncheckedOptionalAccessModel`?**

Currently, the existing configuration (`IgnoreSmartPointerDereference`) is 
being passed into `UncheckedOptionalAccessDiagnoser`, which is not what I need 
in my case.

If I understand correctly, passing `Options` into `Model` requires changes to 
`DataflowAnalysis.h`.

The "cheapest" approach might be to implement code like this 
[here](https://github.com/llvm/llvm-project/blob/c35fbb5460b476ecd210da024eb7c0dda4ad662b/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h#L295):
```cpp
template <typename AnalysisT, typename OptionsT>
auto createAnalysis(ASTContext &ASTCtx, Environment &Env, OptionsT &Options)
    -> decltype(AnalysisT(ASTCtx, Env, OptionsT)) {
  return AnalysisT(ASTCtx, Env, Options);
}
```
Plus, modify the code that calls it and extend the constructor of the 
`UncheckedOptionalAccessModel`.

But, [the `FIXME` comment 
nearby](https://github.com/llvm/llvm-project/blob/c35fbb5460b476ecd210da024eb7c0dda4ad662b/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h#L292)
 highlights that this approach is rather a hack and should be refactored later.

I also see that there is `DataflowAnalysisContext::Options`, but I am not sure 
if it's super useful for my case.

@vbvictor would appreciate your feedback!


https://github.com/llvm/llvm-project/pull/144313
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to