[PATCH] D127898: [clang][dataflow] Add API to separate analysis from diagnosis

Dmitri Gribenko via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Jun 23 09:12:01 PDT 2022

gribozavr2 added inline comments.

Comment at: clang/include/clang/Analysis/FlowSensitive/Diagnosis.h:38
+template <typename Lattice, typename Diag>
+llvm::DenseSet<Diag> diagnoseCFG(
+    const ControlFlowContext &CFCtx,
This function seems pretty general and not necessarily tied to diagnostics.

WDYT about using "visitor" in the name?

For example, "visitDataflowAnalysisResults".

The "Diagnosis" would also become "DataflowAnalysisResultVisitor".

Comment at: clang/include/clang/Analysis/FlowSensitive/Diagnosis.h:42
+    const Environment &Env, TypeErasedDataflowAnalysis &Analysis,
+    Diagnosis<Lattice, llvm::DenseSet<Diag>> Diagnose) {
+  llvm::DenseSet<Diag> Diags;
I'm leaning towards std::vector<Diag> instead of a set, to avoid requiring that Diag is hashable. Users who need hash-based deduplication can easily do it themselves (but why would they have duplication? we only visit each Stmt once)

Comment at: clang/include/clang/Analysis/FlowSensitive/Diagnosis.h:57
+  }
+  return std::move(Diags);
sgatev wrote:
> Better to remove this and rely on NRVO? https://en.cppreference.com/w/cpp/language/copy_elision

Comment at: clang/include/clang/Analysis/FlowSensitive/MatchSwitch.h:49
+template <typename DiagsT> struct DiagnoseState {
+  DiagnoseState(DiagsT &Diags, const Environment &Env)
+      : Diags(Diags), Env(Env) {}
samestep wrote:
> sgatev wrote:
> > samestep wrote:
> > > sgatev wrote:
> > > > Move this to Diagnosis.h?
> > > I'd prefer to keep it in `MatchSwitch.h` alongside `TransferState`, unless we plan to, e.g., move that type to `DataflowAnalysis.h`.
> > Fair enough, but generally I see `TransferState` and `DiagnoseState` as very specific to the dataflow analysis framework whereas `MatchSwitchBuilder` seems to be a bit more generic so I'd consider separating them.
> Sure, if people think it makes sense to put those two types elsewhere then we can do that in a followup.
For now, since there is only a single user, I'd actually prefer to move it into UncheckedOptionalAccessDiagnosis itself. It is a trivial component, basically a std::pair, it seems that exposing it as a public API might not be that helpful.

Comment at: clang/include/clang/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.h:78
+  UncheckedOptionalAccessDiagnosis(
+      ASTContext &AstContext, UncheckedOptionalAccessModelOptions Options = {});
"Diagnosis" sounds like the result. Should this be a "Diagnoser"?

Comment at: clang/unittests/Analysis/FlowSensitive/TestingSupport.h:92
     std::function<AnalysisT(ASTContext &, Environment &)> MakeAnalysis,
-    std::function<void(
-        llvm::ArrayRef<std::pair<
-            std::string, DataflowAnalysisState<typename AnalysisT::Lattice>>>,
-        ASTContext &)>
-        Expectations,
+    std::function<void(AnalysisResults)> Expectations,
     ArrayRef<std::string> Args,
It is better to name a function with a verb. WDYT about "VerifyResults"?

If you agree, please also update the functions below.

Comment at: clang/unittests/Analysis/FlowSensitive/TestingSupport.h:148
+    llvm::StringRef Code,
+    ast_matchers::internal::Matcher<FunctionDecl> FuncMatcher,
+    std::function<AnalysisT(ASTContext &, Environment &)> MakeAnalysis,

Comment at: clang/unittests/Analysis/FlowSensitive/TestingSupport.h:190
+              });
+        }
+        Expectations(Results, AnalysisResults.Context);
Can we use diagnoseCFG to implement the loop above?

Comment at: clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp:1925
   //  )",
-  //      UnorderedElementsAre(Pair("check-1", "unsafe: input.cc:10:9"),
-  //                           Pair("check-2", "safe")));
+  //      "safe");
The original was unsafe, is it an intentional change?

  rG LLVM Github Monorepo



More information about the cfe-commits mailing list